MySQL 物理檔案體繫結構的簡單整理說明

標籤：二進位日誌   原創   idt   可靠   編碼   事務性   結構   串連   查詢   

 

本文出處：http://www.cnblogs.com/wy123/p/7102128.html 
（保留出處並非什麼原創作品權利，本人拙作還遠遠達不到，僅僅是為了連結到原文，因為後續對可能存在的一些錯誤進行修正或補充，無他）

 

本文的資料庫版本是MySQL5.7.18，簡單介紹一下MySQL資料檔案目錄的物理結構和作用，從中可以窺見MySQL的整體上的物理檔案結構以及邏輯功能。
可以從整體結構上瞭解到MySQL的物理體系架構（本人學習的思路往往是被與已瞭解的事物對照學習，或者快速瞭解其輪廓，再逐步細化整個知識體系）
鑒於MySQL中任何一項邏輯性或者物理性檔案都具有可配置性，另外就是由於開源，MySQL在每個大版本中都有一些改進的東西，不能根據某一項或者預設配置生搬硬套。

 

如是MySQL（5.7.18）在Linux系統yum預設安裝的資料檔案目錄，可以看到有如下幾類檔案。

 

1，資料庫路徑：可以看到，系統資料庫和使用者自訂的資料庫都是一個路徑，展開具體的路徑之後是具體的每個資料庫自己的對象）
2，logbin二進位記錄檔：如果開啟了二進位日誌，會有若干個二進位記錄檔（的mysql-bin.000042，mysql-bin.000043）與其對應的描述檔案（mysql-bin.index）
3，redo重做記錄檔：ib_logfile0,ib_logfile1，是支援事務性引擎的redo記錄檔
4，共用資料表空間：ibdata1，如果指定innodb表為非獨立檔案的，使用者自訂庫中的表的資料就儲存在共用資料表空間中。
　　即便是innnodb表指定為獨立資料表空間，使用者自動以庫中的中繼資料資訊（自訂表格的結構資訊，預存程序，觸發器等資訊都儲存在共用資料表空間中）。
　　同時，共用資料表空間還負責儲存undo資料的儲存的作用（undo資料也即事物性操作的資料的修改之前的值）。
　　不過，而從5.6開始，使用者可以把undo log儲存到獨立的tablespace中，並拆分成多個Undo log檔案。
5，暫存資料表空間：ibtemp1，儲存臨時對象的空間，比如暫存資料表對象等。
6，errorlog：error_log.log，記錄啟動、運行或停止MySQL伺服器過程，以及MySQL運行過程中一些較為嚴重的錯誤資訊
7，mysql.sock：作用是MySQL伺服器本身的用戶端串連的時候，發起本地串連時可用
8，slow_log：的MySQL服務中尚未配置慢查詢日誌，如果配置了MySQL的慢查詢日誌，MySQL會將運行過程中的慢查詢日誌記錄到slow_log檔案中
9，general_log:同上面的8，的伺服器尚未配置MySQL的通用查詢日誌，如果配置了通用查詢日誌，MySQL將運行過程中的所有sql都記錄在此檔案中。
10，另外一個是最終的MySQL的設定檔，my.cnf，YUM安裝的MySQL的設定檔my.cnf預設在etc目錄下

 　

 

　　上述檔案可以分類之後用結構化的方式展現出來，如下，也即上述描述的一系列檔案結構的歸類展現
　　需要說明的是，上述列舉的一系列檔案中尚未包括一些檔案，比如啟用複製的時候的中繼記錄檔等等（粗淺拙圖，大神輕噴）

 

 　  

下面對從類別上對各個檔案進行一個簡單的說明：

　　系統資料庫

　　在MySQL5.7.18中，系統資料庫包括information_schema，mysql，sys，performance_schema
　　1，information_schema庫，提供了資料庫的中繼資料資訊，是資料庫的資料，比如資料庫的名字，資料庫中的表名，欄位名，欄位類型等，可以說是資料庫的資料字典資訊。
　　　　這個庫中的資訊並非物理地儲存在表中，而是動態地去讀取其他檔案得到的，比如上面一開始提到的共用資料表空間，對於使用者資料中的對象，比如表結構等，都儲存在共用資料表空間中，
　　　　information_schema庫中的一些資訊可以認為是直接映射到共用資料表空間中的資訊的。
　　2，performance_schema庫，是資料庫效能相關的資訊的資料，記錄的是資料庫伺服器的績效參數。
　　　　1）保留進程等待資訊，包括鎖，互斥變數，檔案資訊等。
　　　　2）儲存曆史事件匯總資訊，為MySQL伺服器效能評估提供參考資訊
　　　　3）配置型選項，來決定是否記錄一些與效能相關的資訊，比如profile資訊等，參考http://www.cnblogs.com/wy123/p/6979499.html
　　3，sys庫，可以根據sys庫中的資料快速瞭解系統的運行資訊，方便地查詢出來資料庫的資訊，在效能瓶頸，自動化吧營運等方面都有很大的協助
　　　　sys庫中的資訊是通過視圖的方式，將information_schema和performance_schema庫中的資料結合起來，可以得到更加直觀和容易理解的資訊
 　  4，mysql庫，儲存了系統的使用者權限資訊及協助資訊，建立的使用者，使用者的許可權資訊的都儲存在MySQL庫。
　　　　比如在修改MySQL的root密碼的時候，都要先use mysql這個系統庫，然後再執行使用者，授權等操作。

　　使用者資料庫

　　使用者資料庫實際上是一個目錄，目錄中儲存了資料庫中的表以及資料資訊，如下是一個典型的資料庫目錄下的檔案資訊。
　　對於innodb引擎的表，一個表分別對應兩個檔案，一個是*.frm，儲存的是表結構資訊，一個是*.ibd，儲存的是表中的資料，從大小也可以看出來*.ibd較大而*.frm較小。
　　另外一個檔案是db.opt，儲存的是資料庫的配置資訊，比如編碼資訊等。
　　對於innodb表，如果是獨立的資料表空間的話，資料庫中的表結構以及資料都儲存在資料庫的路徑下（而不是在共用資料表空間中ibdata1檔案中）
　　但是資料中的其他對象，比如預存程序，觸發器等資訊仍然儲存在共用資料表空間的ibdata1檔案中

 　   test_database1對應的資料庫物理檔案

　　

　　test_database1對應的邏輯資料庫如下

 

 

 基於ibdata1檔案的共用資料表空間

 對於innodb，innodb_file_per_table選項決定了是否啟動獨立資料表空間，MySQL5.7中是預設啟動的，也就是說MySQL的使用者資料庫將使用獨立資料表空間來儲存資料，

 

正如看到的，本測試伺服器的共用資料表空間中只有一個檔案，如下通過show variables like ‘innodb_data%‘;命令可以查詢共用資料表空間的檔案資訊，實際上共用資料表空間可以配置成多個物理檔案。

　　

　　關於共用資料表空間和獨立資料表空間都有各自的優缺點，本文不在抄了，也可以將資料檔案從共用資料表空間轉移到獨立資料表空間。
　　不過從當前（MySQL5.7.18）來看，MySQL預設innodb引擎預設是獨立的資料表空間，讓MySQL資料檔案住上“單間”而不是集體宿舍，可見獨立的資料表空間還是有一定優勢的。

 

 　   基於ibtmp1檔案的暫存資料表空間

　　 暫存資料表空間是儲存全域級，回話級，事物級，檢索級暫存資料表對象的地方，有參數innodb_temp_data_file_path可以看到暫存資料表空間的資訊。

 　　

　　有關暫存資料表空間更多的資訊，請參考：https://yq.aliyun.com/ziliao/89528

　　

　　基於ib_logfileN的重做日誌

　　redo日誌預設情況下有兩個檔案，也即：ib_logfile0和ib_logfile1，如果在資料庫啟動的過程中沒有這兩個檔案，系統會預設自動產生這兩個檔案。
　　預設情況下，ib_logfile0和ib_logfile1是兩個獨立的記錄檔（可以配置的更多個ib_logfile檔案），但是redo日誌的寫入在邏輯上對於ib_logfile0和ib_logfile1是連續的。
　　重做日誌是MySQL事物處理的核心檔案，交易處理的核心之一是一致性，也就是說要麼全做，要麼全不做。
　　事物性操作都是基於一個或者多個表中部分資料的操作，為了保證一致性，在確保事物的一致性的時候，需要事物提交的時候直接或者間接寫盤操作。
　　MySQL事物操作是logwrite-ahead操作，也即先寫日誌（具體怎麼寫日誌取決於innodb_flush_log_at_trx_commit的配置），相當於間接寫盤操作。
　　目的是將對資料庫具體的資料檔案的分散隨機寫入（多個表的資料寫入資料檔案）轉換成基於日誌的順序寫入操作，而資料檔案是非同步寫盤，如果資料檔案寫盤異常，可以通過redo日誌來“重做”，據此來提高事物性操作的效率。
　　redo日誌空間的使用，在邏輯上相當於一個環形空間，redo日誌不斷向前推進寫入記錄，背景定時執行的checkpoint將事務修改過尚未寫盤的記錄非同步寫入資料檔案之後，日誌空間可重用。

 　　

　　

　　undo資料表空間

　　redo重做日誌在提高事物性操作的效率的同時，也通過redo重做機制保證了事物的可靠性。
　　如果事物復原，則需要依賴undo日誌進行復原操作，MySQL在進行事物操作的同時，會記錄事務性操作修改資料之前的資訊，就是undo日誌，確保可以復原到事物發生之前的狀態
　　預設情況下，MySQL將undo日誌記錄在共用資料表空間中（上文提到的bdata1共用檔案），如果事物成功提交，記錄在共用資料表空間的undo日誌會被後台進程做puege清理
　　當然這個undo日誌也有差別，如果是update操作之後提交事務，undo日誌還需要為MVCC提供伺服器，如果是insert操作，事物提交之後可以直接清理復原日誌記錄。

 　　不過，而從5.6開始，使用者可以把undo log儲存到獨立的tablespace中，並拆分成多個Undo log檔案。　　詳情參考：http://mysqllover.com/?p=873

　　

 總結：

　　本位粗淺地分析了MySQL物理檔案的結構以及對應的邏輯功能，多數配置是按照預設情況下來進行展現的，從中可以對MySQL的物理結構以及邏輯功能進行一個簡單又粗淺的說明（很粗很淺，歡迎指正）。
　　但終究是窺探管中窺豹僅見一斑而已，路曼曼其修遠。
　　再次說明，MySQL每一步都是可配置化的，配置不同，甚至每個MySQL的髮型版本，某些地方都不盡一致，切勿照搬。

 

MySQL 物理檔案體繫結構的簡單整理說明