本篇文章給大家帶來了關于mysql的相關知識,其中主要介紹了關于架構原理的相關內容,MySQL Server架構自頂向下大致可以分網絡連接層、服務層、存儲引擎層和系統文件層,下面一起來看一下,希望對大家有幫助。
推薦學習:mysql視頻教程
Mysql 架構原理
1、Mysql體系架構
MySQL Server架構自頂向下大致可以分網絡連接層、服務層、存儲引擎層和系統文件層。
網絡連接層
- 客戶端連接器(Client Connectors):提供與MySQL服務器建立的支持。目前幾乎支持所有主流的服務端編程技術,例如常見的 Java、C、Python、.NET等,它們通過各自API技術與MySQL建立連接。
服務層(MySQL Server)
服務層是MySQL Server的核心,主要包含系統管理和控制工具、連接池、SQL接口、解析器、查詢優化器和緩存六個部分。
-
連接池(Connection Pool):負責存儲和管理客戶端與數據庫的連接,一個線程負責管理一個連接。
-
系統管理和控制工具(Management Services & Utilities):例如備份恢復、安全管理、集群管理等
-
SQL接口(SQL Interface):用于接受客戶端發送的各種SQL命令,并且返回用戶需要查詢的結果。比如DML、DDL、存儲過程、視圖、觸發器等。
-
解析器(Parser):負責將請求的SQL解析生成一個"解析樹"。然后根據一些MySQL規則進一步檢查解析樹是否合法。
-
查詢優化器(Optimizer):當"解析樹"通過解析器語法檢查后,將交由優化器將其轉化成執行計劃,然后與存儲引擎交互。
select uid, name from user where gender = 1;
選取 –》投影 –》聯接 策略
- select先根據where語句進行選取,并不是查詢出全部數據再過濾;
- select查詢根據uid和name進行屬性投影,并不是取出所有字段;
- 將前面選取和投影聯接起來最終生成查詢結果;
-
緩存(Cache&Buffer): 緩存機制是由一系列小緩存組成的。比如表緩存,記錄緩存,權限緩存,引擎緩存等。如果查詢緩存有命中的查詢結果,查詢語句就可以直接去查詢緩存中取數據。
存儲引擎層(Pluggable Storage Engines)
- 存儲引擎負責MySQL中數據的存儲與提取,與底層系統文件進行交互。MySQL存儲引擎是插件式的,服務器中的查詢執行引擎通過接口與存儲引擎進行通信,接口屏蔽了不同存儲引擎之間的差異 。現在有很多種存儲引擎,各有各的特點,最常見的是MyISAM和InnoDB。
系統文件層(File System)
該層負責將數據庫的數據和日志存儲在文件系統之上,并完成與存儲引擎的交互,是文件的物理存儲層。主要包含日志文件,數據文件,配置文件,pid 文件,socket 文件等。
- 日志文件
- 錯誤日志(Error log)
- 默認開啟,show variables like ‘%log_error%’;
- 通用查詢日志(General query log)
- 記錄一般查詢語句,show variables like ‘%general%’;
- 二進制日志(binary log)
- 記錄了對MySQL數據庫執行的更改操作,并且記錄了語句的發生時間、執行時長;但是它不記錄select、show等不修改數據庫的SQL。主要用于數據庫恢復和主從復制。
- show variables like ‘%log_bin%’; //是否開啟
- show variables like ‘%binlog%’; //參數查看
- show binary logs;//查看日志文件
- 慢查詢日志(Slow query log)
- 記錄所有執行時間超時的查詢SQL,默認是10秒。
- show variables like ‘%slow_query%’; //是否開啟
- show variables like ‘%long_query_time%’; //時長
- 錯誤日志(Error log)
- 配置文件
- 用于存放MySQL所有的配置信息文件,比如my.cnf、my.ini等。
- 數據文件
- db.opt 文件:記錄這個庫的默認使用的字符集和校驗規則。
- frm 文件:存儲與表相關的元數據(meta)信息,包括表結構的定義信息等,每一張表都會有一個frm 文件。
- MYD 文件:MyISAM 存儲引擎專用,存放 MyISAM 表的數據(data),每一張表都會有一個.MYD 文件。
- MYI 文件:MyISAM 存儲引擎專用,存放 MyISAM 表的索引相關信息,每一張 MyISAM 表對應一個 .MYI文件。
- ibd文件和 IBDATA 文件:存放 InnoDB 的數據文件(包括索引)。InnoDB 存儲引擎有兩種表空間方式:獨享表空間和共享表空間。獨享表空間使用 .ibd 文件來存放數據,且每一張InnoDB 表對應一個 .ibd 文件。共享表空間使用 .ibdata 文件,所有表共同使用一個(或多個,自行配置).ibdata 文件。
- ibdata1 文件:系統表空間數據文件,存儲表元數據、Undo日志等 。
- ib_logfile0、ib_logfile1 文件:Redo log 日志文件。
- pid 文件
- pid 文件是 mysqld 應用程序在 Unix/Linux 環境下的一個進程文件,和許多其他 Unix/Linux 服務端程序一樣,它存放著自己的進程 id。
- socket 文件
- socket 文件也是在 Unix/Linux 環境下才有的,用戶在 Unix/Linux 環境下客戶端連接可以不通過TCP/IP 網絡而直接使用 Unix Socket 來連接 MySQL。
2、MySQL運行機制
- 建立連接(Connectors&Connection Pool),通過客戶端/服務器通信協議與MySQL建立連接。MySQL 客戶端與服務端的通信方式是 “ 半雙工 ”。對于每一個 MySQL 的連接,時刻都有一個線程狀態來標識這個連接正在做什么。
- 通訊機制:
- 全雙工:能同時發送和接收數據,例如平時打電話。
- 半雙工:指的某一時刻,要么發送數據,要么接收數據,不能同時。例如早期對講機
- 單工:只能發送數據或只能接收數據。例如單行道;
- 線程狀態:show processlist; //查看用戶正在運行的線程信息,root用戶能查看所有線程,其他用戶只能看自己的;
- id:線程ID,可以使用kill xx;
- user:啟動這個線程的用戶
- Host:發送請求的客戶端的IP和端口號
- db:當前命令在哪個庫執行
- Command:該線程正在執行的操作命令
- Create DB:正在創建庫操作
- Drop DB:正在刪除庫操作
- Execute:正在執行一個PreparedStatement
- Close Stmt:正在關閉一個PreparedStatement
- Query:正在執行一個語句
- Sleep:正在等待客戶端發送語句
- Quit:正在退出
- Shutdown:正在關閉服務器
- Time:表示該線程處于當前狀態的時間,單位是秒
- State:線程狀態
- Updating:正在搜索匹配記錄,進行修改
- Sleeping:正在等待客戶端發送新請求
- Starting:正在執行請求處理
- Checking table:正在檢查數據表
- Closing table : 正在將表中數據刷新到磁盤中
- Locked:被其他查詢鎖住了記錄
- Sending Data:正在處理Select查詢,同時將結果發送給客戶端
- Info:一般記錄線程執行的語句,默認顯示前100個字符。想查看完整的使用show full processlist;
- 通訊機制:
- 查詢緩存(Cache&Buffer),這是MySQL的一個可優化查詢的地方,如果開啟了查詢緩存且在查詢緩存過程中查詢到完全相同的SQL語句,則將查詢結果直接返回給客戶端;如果沒有開啟查詢緩存或者沒有查詢到完全相同的 SQL 語句則會由解析器進行語法語義解析,并生成“解析樹”。
- 緩存Select查詢的結果和SQL語句;
- 執行Select查詢時,先查詢緩存,判斷是否存在可用的記錄集,要求是否完全相同(包括參數值),這樣才會匹配緩存數據命中;
- 即使開啟查詢緩存,以下SQL也不能緩存:
- 查詢語句使用SQL_NO_CACHE
- 查詢的結果大于query_cache_limit設置
- 查詢中有一些不確定的參數,比如now()
- show variables like ‘%query_cache%’; //查看查詢緩存是否啟用,空間大小,限制等
- show status like ‘Qcache%’; //查看更詳細的緩存參數,可用緩存空間,緩存塊,緩存多少等
- 解析器(Parser)將客戶端發送的SQL進行語法解析,生成"解析樹"。預處理器根據一些MySQL規則進一步檢查“解析樹”是否合法,例如這里將檢查數據表和數據列是否存在,還會解析名字和別名,看看它們是否有歧義,最后生成新的“解析樹”。
- 查詢優化器(Optimizer)根據“解析樹”生成最優的執行計劃。MySQL使用很多優化策略生成最優的執行計劃,可以分為兩類:靜態優化(編譯時優化)、動態優化(運行時優化)。
- 等價變換策略
- 5=5 and a>5 改成 a > 5
- a < b and a=5 改成b>5 and a=5
- 基于聯合索引,調整條件位置等
- 優化count、min、max等函數
- InnoDB引擎min函數只需要找索引最左邊
- InnoDB引擎max函數只需要找索引最右邊
- MyISAM引擎count(*),不需要計算,直接返回
- 提前終止查詢
- 使用了limit查詢,獲取limit所需的數據,就不在繼續遍歷后面數據
- in的優化
- MySQL對 in 查詢,會先進行排序,再采用二分法查找數據。比如where id in (2,1,3),變成 in (1,2,3);
- 等價變換策略
- 查詢執行引擎負責執行 SQL 語句,此時查詢執行引擎會根據 SQL 語句中表的存儲引擎類型,以及對應的API接口與底層存儲引擎緩存或者物理文件的交互,得到查詢結果并返回給客戶端。若開啟用查詢緩存,這時會將SQL 語句和結果完整地保存到查詢緩存(Cache&Buffffer)中,以后若有相同的 SQL 語句執行則直接返回結果。
- 如果開啟了查詢緩存,先將查詢結果做緩存操作
- 返回結果過多,采用增量模式返回
- 開始執行的時候,要先判斷一下你對這個表 T 有沒有執行查詢的權限,如果沒有,就會返回沒有權限的錯誤,(如果命中查詢緩存,會在查詢緩存返回結果的時候,做權限驗證。查詢也會在優化器之前調用 precheck 驗證權限)。
- 如果有權限,就打開表繼續執行。打開表的時候,執行器就會根據表的引擎定義,去使用這個引擎提供的接口。執行器的執行流程是這樣的:
- select * from test where age > 10;
- 調用 InnoDB 引擎接口取這個表的第一行,判斷 age 值是不是 10,如果不是則跳過,如果是則將這行存在結果集中;
- 調用引擎接口取“下一行”,重復相同的判斷邏輯,直到取到這個表的最后一行。
- 執行器將上述遍歷過程中所有滿足條件的行組成的記錄集作為結果集返回給客戶端。
3、Mysql存儲引擎
存儲引擎在MySQL的體系架構中位于第三層,負責MySQL中的數據的存儲和提取,是與文件打交道的子系統,它是根據MySQL提供的文件訪問層抽象接口定制的一種文件訪問機制,這種機制就叫作存儲引擎。
使用show engines命令,就可以查看當前數據庫支持的引擎信息。
在5.5版本之前默認采用MyISAM存儲引擎,從5.5開始采用InnoDB存儲引擎。
- InnoDB:支持事務,具有提交,回滾和崩潰恢復能力,事務安全;
- MyISAM:不支持事務和外鍵,訪問速度快;
- Memory:利用內存創建表,訪問速度非常快,因為數據在內存,而且默認使用Hash索引,但是一旦關閉,數據就會丟失;
- Archive:歸檔類型引擎,僅能支持insert和select語句;
- Csv:以CSV文件進行數據存儲,由于文件限制,所有列必須強制指定not null,另外CSV引擎也不支持索引和分區,適合做數據交換的中間表;
- BlackHole: 黑洞,只進不出,進來消失,所有插入數據都不會保存;
- Federated:可以訪問遠端MySQL數據庫中的表。一個本地表,不保存數據,訪問遠程表內容。
- MRG_MyISAM:一組MyISAM表的組合,這些MyISAM表必須結構相同,Merge表本身沒有數據,對Merge操作可以對一組MyISAM表進行操作;
InnoDB和MyISAM對比
- 事務和外鍵
- InnoDB支持事務和外鍵,具有安全性和完整性,適合大量insert或update操作
- MyISAM不支持事務和外鍵,它提供高速存儲和檢索,適合大量的select查詢操作
- 鎖機制
- InnoDB支持行級鎖,鎖定指定記錄。基于索引來加鎖實現。
- MyISAM支持表級鎖,鎖定整張表。
- 索引結構
- InnoDB使用聚集索引(聚簇索引),索引和記錄在一起存儲,既緩存索引,也緩存記錄。
- MyISAM使用非聚集索引(非聚簇索引),索引和記錄分開。
- 并發處理能力
- MyISAM使用表鎖,會導致寫操作并發率低,讀之間并不阻塞,讀寫阻塞。
- InnoDB讀寫阻塞可以與隔離級別有關,可以采用多版本并發控制(MVCC)來支持高并發
- 存儲文件
- InnoDB表對應兩個文件,一個.frm表結構文件,一個.ibd數據文件。InnoDB表最大支持64TB;
- MyISAM表對應三個文件,一個.frm表結構文件,一個MYD表數據文件,一個.MYI索引文件。從
MySQL5.0開始默認限制是256TB。
- 適用場景
- MyISAM
- 不需要事務支持(不支持)
- 并發相對較低(鎖定機制問題)
- 數據修改相對較少,以讀為主
- 數據一致性要求不高
- InnoDB
- 需要事務支持(具有較好的事務特性)
- 行級鎖定對高并發有很好的適應能力
- 數據更新較為頻繁的場景
- 數據一致性要求較高
- 硬件設備內存較大,可以利用InnoDB較好的緩存能力來提高內存利用率,減少磁盤IO
- MyISAM
- 總結
- 兩種引擎該如何選擇?
- 是否需要事務?有,InnoDB
- 是否存在并發修改?有,InnoDB
- 是否追求快速查詢,且數據修改少?是,MyISAM
- 在絕大多數情況下,推薦使用InnoDB
- 兩種引擎該如何選擇?
InnoDB存儲結構
從MySQL 5.5版本開始默認使用InnoDB作為引擎,它擅長處理事務,具有自動崩潰恢復的特性。下面是官方的InnoDB引擎架構圖,主要分為內存結構和磁盤結構兩大部分。
InnoDB內存結構
內存結構主要包括Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大組件。
- Buffer Pool:緩沖池,簡稱BP。BP以Page頁為單位,默認大小16K,BP的底層采用鏈表數據結構管理Page。在InnoDB訪問表記錄和索引時會在Page頁中緩存,以后使用可以減少磁盤IO操作,提升效率。
- Page管理機制
- Page根據狀態可以分為三種類型:
- free page : 空閑page,未被使用
- clean page:被使用page,數據沒有被修改過
- dirty page:臟頁,被使用page,數據被修改過,頁中數據和磁盤的數據產生了不一致
- 針對上述三種page類型,InnoDB通過三種鏈表結構來維護和管理:
- free list :表示空閑緩沖區,管理free page
- flush list:表示需要刷新到磁盤的緩沖區,管理dirty page,內部page按修改時間排序。臟頁即存在于flush鏈表,也在LRU鏈表中,但是兩種互不影響,LRU鏈表負責管理page的可用性和放,而flush鏈表負責管理臟頁的刷盤操作。
- lru list:表示正在使用的緩沖區,管理clean page和dirty page,緩沖區以midpoint為基點,前面鏈表稱為new列表區,存放經常訪問的數據,占63%;后面的鏈表稱為old列表區,存放使用較少數據,占37%。
- Page根據狀態可以分為三種類型:
- 改進型LRU算法維護
- 普通LRU:末尾淘汰法,新數據從鏈表頭部加入,釋放空間時從末尾淘汰
- 改性LRU:鏈表分為new和old兩個部分,加入元素時并不是從表頭插入,而是從中間midpoint位置插入,如果數據很快被訪問,那么page就會向new列表頭部移動,如果數據沒有被訪問,會逐步向old尾部移動,等待淘汰。
- 每當有新的page數據讀取到buffer pool時,InnoDb引擎會判斷是否有空閑頁,是否足夠,如果有就將free page從free list列表刪除,放入到LRU列表中。沒有空閑頁,就會根據LRU算法淘汰LRU鏈表默認的頁,將內存空間釋放分配給新的頁。
- Buffer Pool配置參數
- show variables like ‘%innodb_page_size%’; //查看page頁大小
- show variables like ‘%innodb_old%’; //查看lru list中old列表參數
- show variables like ‘%innodb_buffer%’; //查看buffffer pool參數
- 建議:將innodb_buffer_pool_size設置為總內存大小的60%-80%,innodb_buffer_pool_instances可以設置為多個,這樣可以避免緩存爭奪。
- Page管理機制
- Change Buffer:寫緩沖區,簡稱CB。在進行DML操作時,如果BP沒有其相應的Page數據,并不會立刻將磁盤頁加載到緩沖池,而是在CB記錄緩沖變更,等未來數據被讀取時,再將數據合并恢復到BP中。
- ChangeBuffer占用BufferPool空間,默認占25%,最大允許占50%,可以根據讀寫業務量來進行調整。參數innodb_change_buffer_max_size;
- 當更新一條記錄時,該記錄在BufferPool存在,直接在BufferPool修改,一次內存操作。如果該記錄在BufferPool不存在(沒有命中),會直接在ChangeBuffer進行一次內存操作,不用再去磁盤查詢數據,避免一次磁盤IO。當下次查詢記錄時,會先進性磁盤讀取,然后再從ChangeBuffer中讀取信息合并,最終載入BufferPool中。
- 寫緩沖區,僅適用于非唯一普通索引頁
- 如果在索引設置唯一性,在進行修改時,InnoDB必須要做唯一性校驗,因此必須查詢磁盤,做一次IO操作。會直接將記錄查詢到BufferPool中,然后在緩沖池修改,不會在ChangeBuffer操作。
- Adaptive Hash Index:自適應哈希索引,用于優化對BP數據的查詢。InnoDB存儲引擎會監控對表索引的查找,如果觀察到建立哈希索引可以帶來速度的提升,則建立哈希索引,所以稱之為自適應。InnoDB存儲引擎會自動根據訪問的頻率和模式來為某些頁建立哈希索引。
- Log Buffer:日志緩沖區,用來保存要寫入磁盤上log文件(Redo/Undo)的數據,日志緩沖區的內容定期刷新到磁盤log文件中。日志緩沖區滿時會自動將其刷新到磁盤,當遇到BLOB或多行更新的大事務操作時,增加日志緩沖區可以節省磁盤I/O。
- LogBuffer主要是用于記錄InnoDB引擎日志,在DML操作時會產生Redo和Undo日志;
- LogBuffer空間滿了,會自動寫入磁盤。可以通過將innodb_log_buffer_size參數調大,減少磁盤IO頻率;
- innodb_flush_log_at_trx_commit參數控制日志刷新行為,默認為1
- 0 : 每隔1秒寫日志文件和刷盤操作(寫日志文件LogBuffer –> OS cache,刷盤OScache –> 磁盤文件),最多丟失1秒數據
- 1:事務提交,立刻寫日志文件和刷盤,數據不丟失,但是會頻繁IO操作
- 2:事務提交,立刻寫日志文件,每隔1秒鐘進行刷盤操作
InnoDB磁盤結構
InnoDB磁盤主要包含Tablespaces,InnoDB Data Dictionary,Doublewrite Buffer、Redo Log和Undo Logs。
-
表空間(Tablespaces):用于存儲表結構和數據。表空間又分為系統表空間、獨立表空間、通用表空間、臨時表空間、Undo表空間等多種類型;
-
系統表空間(The System Tablespace)
- 包含InnoDB數據字典,Doublewrite Buffer,Change Buffer,Undo Logs的存儲區域。系統表空間也默認包含任何用戶在系統表空間創建的表數據和索引數據。系統表空間是一個共享的表空間因為它是被多個表共享的。該空間的數據文件通過參數innodb_data_file_path控制,默認值是ibdata1:12M:autoextend(文件名為ibdata1、12MB、自動擴展)。
-
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; //創建表空 間ts1 CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; //將表添加到ts1 表空間
-
獨立表空間(File-Per-Table Tablespaces)
- 默認開啟,獨立表空間是一個單表表空間,該表創建于自己的數據文件中,而非創建于系統表空間中。當innodb_file_per_table選項開啟時,表將被創建于表空間中。否則,innodb將被創建于系統表空間中。每個表文件表空間由一個.ibd數據文件代表,該文件默認被創建于數據庫目錄中。表空間的表文件支持動態(dynamic)和壓縮(commpressed)行格式。
-
通用表空間(General Tablespaces)
- 通用表空間為通過create tablespace語法創建的共享表空間。通用表空間可以創建于mysql數據目錄外的其他表空間,其可以容納多張表,且其支持所有的行格式。
-
撤銷表空間(Undo Tablespaces)
- 撤銷表空間由一個或多個包含Undo日志文件組成。在MySQL 5.7版本之前Undo占用的是System Tablespace共享區,從5.7開始將Undo從System Tablespace分離了出來。
- InnoDB使用的undo表空間由innodb_undo_tablespaces配置選項控制,默認為0。參數值為0表示使用系統表空間ibdata1;大于0表示使用undo表空間undo_001、undo_002等。
-
臨時表空間(Temporary Tablespaces)
- 分為session temporary tablespaces 和global temporary tablespace兩種:
- session temporary tablespaces 存儲的是用戶創建的臨時表和磁盤內部的臨時表。
- global temporary tablespace儲存用戶臨時表的回滾段(rollback segments )。mysql服務器正常關閉或異常終止時,臨時表空間將被移除,每次啟動時會被重新創建。
- 分為session temporary tablespaces 和global temporary tablespace兩種:
-
-
數據字典(InnoDB Data Dictionary)
- InnoDB數據字典由內部系統表組成,這些表包含用于查找表、索引和表字段等對象的元數據。元數據物理上位于InnoDB系統表空間中。由于歷史原因,數據字典元數據在一定程度上與InnoDB表元數據文件(.frm文件)中存儲的信息重疊。
-
雙寫緩沖區(Doublewrite Buffer)
- 位于系統表空間,是一個存儲區域。在BufferPage的page頁刷新到磁盤真正的位置前,會先將數據存在Doublewrite 緩沖區。如果在page頁寫入過程中出現操作系統、存儲子系統或mysqld進程崩潰,InnoDB可以在崩潰恢復期間從Doublewrite 緩沖區中找到頁面的一個好備份。在大多數情況下,默認情況下啟用雙寫緩沖區,要禁用Doublewrite 緩沖區,可以將innodb_doublewrite設置為0。使用Doublewrite 緩沖區時建議將innodb_flush_method設置為O_DIRECT。
- MySQL的innodb_flush_method這個參數控制著innodb數據文件及redo log的打開、刷寫模式。有三個值:fdatasync(默認),O_DSYNC,O_DIRECT。設置O_DIRECT表示數據文件寫入操作會通知操作系統不要緩存數據,也不要用預讀,直接從InnodbBuffer寫到磁盤文件。
- 默認的fdatasync意思是先寫入操作系統緩存,然后再調用fsync()函數去異步刷數據文件與redo log的緩存信息。
- 位于系統表空間,是一個存儲區域。在BufferPage的page頁刷新到磁盤真正的位置前,會先將數據存在Doublewrite 緩沖區。如果在page頁寫入過程中出現操作系統、存儲子系統或mysqld進程崩潰,InnoDB可以在崩潰恢復期間從Doublewrite 緩沖區中找到頁面的一個好備份。在大多數情況下,默認情況下啟用雙寫緩沖區,要禁用Doublewrite 緩沖區,可以將innodb_doublewrite設置為0。使用Doublewrite 緩沖區時建議將innodb_flush_method設置為O_DIRECT。
-
重做日志(Redo Log)
- 重做日志是一種基于磁盤的數據結構,用于在崩潰恢復期間更正不完整事務寫入的數據。MySQL以循環方式寫入重做日志文件,記錄InnoDB中所有對Buffer Pool修改的日志。當出現實例故障(像斷電),導致數據未能更新到數據文件,則數據庫重啟時須redo,重新把數據更新到數據文件。讀寫事務在執行的過程中,都會不斷的產生redo log。默認情況下,重做日志在磁盤上由兩個名為ib_logfile0和ib_logfile1的文件物理表示。
-
撤銷日志(Undo Logs)
- 撤消日志是在事務開始之前保存的被修改數據的備份,用于例外情況時回滾事務。撤消日志屬于邏輯日志,根據每行記錄進行記錄。撤消日志存在于系統表空間、撤消表空間和臨時表空間中。
新版本結構演變
- MySQL 5.7 版本
- 將 Undo日志表空間從共享表空間 ibdata 文件中分離出來,可以在安裝 MySQL 時由用戶自行指定文件大小和數量。
- 增加了 temporary 臨時表空間,里面存儲著臨時表或臨時查詢結果集的數據。
- Buffer Pool 大小可以動態修改,無需重啟數據庫實例。
- MySQL 8.0 版本
- 將InnoDB表的數據字典和Undo都從共享表空間ibdata中徹底分離出來了,以前需要ibdata中數據字典與獨立表空間ibd文件中數據字典一致才行,8.0版本就不需要了。
- temporary 臨時表空間也可以配置多個物理文件,而且均為 InnoDB 存儲引擎并能創建索引,這樣加快了處理的速度。
- 用戶可以像 Oracle 數據庫那樣設置一些表空間,每個表空間對應多個物理文件,每個表空間可以給多個表使用,但一個表只能存儲在一個表空間中。
- 將Doublewrite Buffer從共享表空間ibdata中也分離出來了。
InnoDB線程模型
- IO Thread
- 在InnoDB中使用了大量的AIO(Async IO)來做讀寫處理,這樣可以極大提高數據庫的性能。在
InnoDB共有10個IO Thread,分別是4個write,4個read,1個insert buffer和 1個log thread。- read thread : 負責讀取操作,將數據從磁盤加載到緩存page頁。4個
- write thread:負責寫操作,將緩存臟頁刷新到磁盤。4個
- log thread:負責將日志緩沖區內容刷新到磁盤。1個
- insert buffer thread :負責將寫緩沖內容刷新到磁盤。1個
- 在InnoDB中使用了大量的AIO(Async IO)來做讀寫處理,這樣可以極大提高數據庫的性能。在
- Purge Thread
- 事務提交之后,其使用的undo日志將不再需要,因此需要Purge Thread回收已經分配的undo頁。
- show variables like ‘%innodb_purge_threads%’;
- Page Cleaner Thread
- 作用是將臟數據刷新到磁盤,臟數據刷盤后相應的redo log也就可以覆蓋,即可以同步數據,又能
達到redo log循環使用的目的。會調用write thread線程處理。 - show variables like ‘%innodb_page_cleaners%’;
- 作用是將臟數據刷新到磁盤,臟數據刷盤后相應的redo log也就可以覆蓋,即可以同步數據,又能
- Master Thread
- Master thread是InnoDB的主線程,負責調度其他各線程,優先級最高。作用是將緩沖池中的數據異步刷新到磁盤 ,保證數據的一致性。包含:臟頁的刷新(page cleaner thread)、undo頁回收(purge thread)、redo日志刷新(log thread)、合并寫緩沖等。內部有兩個主處理,分別是每隔1秒和10秒處理。
- 每1秒的操作:
- 刷新日志緩沖區,刷到磁盤
- 合并寫緩沖區數據,根據IO讀寫壓力來決定是否操作
- 刷新臟頁數據到磁盤,根據臟頁比例達到75%才操作(innodb_max_dirty_pages_pct,
innodb_io_capacity)
- 每10秒的操作:
- 刷新臟頁數據到磁盤
- 合并寫緩沖區數據
- 刷新日志緩沖區
- 刪除無用的undo頁
InnoDB數據文件
InnoDB文件存儲結構
-
InnoDB數據文件存儲結構
- 分為 ibd數據文件 –> Segment(段)–>Extent(區)–> Page(頁)–>Row(行)
- Tablesapce表空間,用于存儲多個ibd數據文件,用于存儲表的記錄和索引。一個文件包含多個段。
- Segment段,用于管理多個Extent,分為數據段(Leaf node segment)、索引段(Non-leaf node
segment)、回滾段(Rollback segment)。一個表至少會有兩個segment,一個管理數據,一個管理索引。每多創建一個索引,會多兩個segment。 - Extent區,一個區固定包含64個連續的頁,大小為1M。當表空間不足,需要分配新的頁資源,不會
一頁一頁分,直接分配一個區。 - Page頁,用于存儲多個Row行記錄,大小為16K。包含很多種頁類型,比如數據頁,undo頁,系統頁,事務數據頁,大的BLOB對象頁。
- Row行,包含了記錄的字段值,事務ID(Trx id)、滾動指針(Roll pointer)、字段指針(Field
pointers)等信息。
-
Page是文件最基本的單位,無論何種類型的page,都是由page header,page trailer和page body組成。如下圖所示
- 分為 ibd數據文件 –> Segment(段)–>Extent(區)–> Page(頁)–>Row(行)
-
InnoDB文件存儲格式
-
通過 SHOW TABLE STATUS 命令 查看
-
一般情況下,如果row_format為REDUNDANT、COMPACT,文件格式為Antelope;如果row_format為DYNAMIC和COMPRESSED,文件格式為Barracuda。
-
通過 information_schema 查看指定表的文件格式
-
select * from information_schema.innodb_sys_tables;
-
-
-
-
File文件格式(File-Format)
- 在早期的InnoDB版本中,文件格式只有一種,隨著InnoDB引擎的發展,出現了新文件格式,用于支持新的功能。目前InnoDB只支持兩種文件格式:Antelope 和 Barracuda。
- Antelope: 先前未命名的,最原始的InnoDB文件格式,它支持兩種行格式:COMPACT和REDUNDANT,MySQL 5.6及其以前版本默認格式為Antelope。
- Barracuda: 新的文件格式。它支持InnoDB的所有行格式,包括新的行格式:COMPRESSED和 DYNAMIC。
- 通過innodb_file_format 配置參數可以設置InnoDB文件格式,之前默認值為Antelope,5.7版本開始改為Barracuda。
- 在早期的InnoDB版本中,文件格式只有一種,隨著InnoDB引擎的發展,出現了新文件格式,用于支持新的功能。目前InnoDB只支持兩種文件格式:Antelope 和 Barracuda。
-
Row行格式(Row_format)
-
表的行格式決定了它的行是如何物理存儲的,這反過來又會影響查詢和DML操作的性能。如果在單個page頁中容納