本章將會分析構成MySQL資料庫和InnoDB儲存引擎的各種型別檔案，這些檔案有如下幾種：
引數檔案：主要是儲存了MySQL資料庫相關引數的檔案，比如指定存放資料庫路徑、初始化引數、記憶體大小等的配置。
日誌檔案：包括錯誤日誌檔案、二進位制日誌檔案、慢查詢日誌檔案、查詢日誌檔案等。
socket檔案：當用unix域套接字方式進行連線時需要的檔案。
pid檔案：MySQL例項的程序pid檔案。
MySQL表結構檔案：用來存放MySQL表結構定義檔案。
儲存引擎檔案：MySQL裡面每個儲存引擎都會有自己的檔案來儲存各種資料，記錄了對應的資料記錄和索引資料等。

一、引數檔案
MySQL引數檔案主要是my.cnf檔案，裡面儲存了各種配置引數，除了配置檔案之外，還可以連線到資料庫使用sql語句對引數進行查詢或者設定，這裡推薦使用 show variables語句，返回內容太多如果需要過濾的可以使用 like ‘%關鍵字%’，如下圖所示：

查詢包含 buffer 關鍵字的引數資訊，比如 innodb_buffer_pool_size 這個引數就是InnoDB引擎設定記憶體池大小的。

MySQL資料庫中的引數可以分為兩類：動態（dynamic）引數 和 靜態（static）引數。動態引數意味著在MySQL執行中可以更改的，靜態引數則是在執行中不可修改的。

對應動態引數，可以使用 set 語句進行修改，具體語法如下所示：

set
|[global|session] system_var_name = expr
|[@@global.|@@session.|@@]system_var_name = expr

其中 global 代表的是全域性，session代表只針對當前連接回話。

二、日誌檔案
錯誤日誌（error log）

錯誤日誌這個很好理解，就是記錄了MySQL的相關執行錯誤日誌，執行 show variables like ‘log_error’ 語句可以看到錯誤日誌檔案路徑，通常情況下是/var/log/mysql/error.log

慢查詢日誌（slow query log）

慢查詢日誌，記錄的是那些執行時間過長的sql語句，long_query_time 引數用於設定慢查詢的閥值時間，預設是10.000000，代表10秒，具體使用者可以根據自身需求設定。執行語句 show variables like ‘%slow%’; 可以檢視慢查詢的相關設定，比如慢查詢的日誌檔案路徑等，如下圖示

除了記錄執行時間過長的sql語句之外，MySQL還提供了記錄未使用索引的sql語句，具體引數是 log_queries_not_using_indexes，同樣也是記錄到慢查詢日誌檔案裡面。MySQL 5.6.5版本之後還提供了 log_throttle_queries_not_using_indexes 引數，用於防止過多地刷沒使用索引的sql語句把慢查詢日誌檔案撐大。

從MySQL 5.1開始，可以將慢查詢日誌記錄儲存在資料表格中，慢查詢表在mysql資料庫下，名叫slow_log，引數log_ouput指定了輸出的目標，預設為FILE，可以將它設定為TABLE，就可以寫入資料庫表格了。

查詢日誌（log）
查詢日誌記錄了所有對MySQL資料庫請求的資訊，預設情況下查詢日誌是沒有開啟的，具體可以通過 show variables like ‘%general_log%’ 語句查詢，如下圖示

查詢日誌跟慢查詢日誌一樣，都是可以通過log_output引數指定儲存到資料庫表格，表格名稱是general_log。

二進位制日誌（bin log）
二進位制日誌記錄了對資料庫執行了更改的所有操作，不包括類似select、show不會對資料產生變更的操作記錄。但是對於會產生資料變更的如update等指令，就算最終沒有對資料進行更改也一樣會記錄到bin log裡面。

設計bin log主要有以下幾個作用：
恢復：因為bin log記錄的是所有資料記錄的更改操作流水資訊，所以可以通過bin log日誌會恢復資料。
複製：複製跟恢復原理類似，主要是用於在搭建備機或者叢集需要用到，用作將資料同步到其他節點。
審計：管理員可以通過bin log做資訊審計，判斷是否有被注入篡改資料的行為。

通過配置檔案my.cnf引數log-bin[=name]可以啟動bin log，預設情況下是不開啟的，其中name是可選項，用於標記bin log的檔名，如果不指定則用主機名。通常情況下，bin log儲存在資料庫資料目錄 datadir 路徑，一般是/var/lib/mysql/，檔名格式是 [name|hostname]-bin.xxxxx，其中xxxxx是序列號，還有一個叫[name|hostname]-bin.index的bin log索引檔案，用來儲存產生的bin log序列號。

下面幾個引數會對bin log行為有影響：

max_binlog_size 指定單個bin log檔案最大值

binlog_cache_size 當使用事務引擎時，所有未提交（commit）的bin log會被記錄到緩衝區，等待事務提交時直接將緩衝區的bin log寫入bin log檔案，該緩衝區大小則為該引數所指定。需要注意的是，這個引數是基於會話（session）的。

sync_binlog 預設情況下，bin log不是每次寫都馬上同步到磁碟去，這樣就會存在當bin log還沒刷到磁碟就宕機導致bin log資料丟失。該引數則是用於設定寫bin log緩衝區多少次就同步到磁碟，sync_binlog=1則代表每次都寫入磁碟，就相當於同步

binlog-do-db 標記需要寫入bin log的資料庫，預設為空，則代表所有資料庫都需要同步bin log。

binlog-ignore-db 跟上面的binlog-do-db相反，指定那些資料庫不需要同步bin log。

log-slave-update 如果當前伺服器是複製中的slave角色，那麼它不會降從master取得並執行的bin log日誌寫入自己的bin log檔案。如果需要寫入，則需要設定該引數，通常是搭建 master -> slave -> slave 架構需要。

binlog_format 該引數可以設定的值有 STATEMENT、ROW、MIXED。
STATEMENT代表bin log記錄的是sql語句（這種方式有缺陷，比如記錄的是函式語句，如rand、uuid這些在不同伺服器上執行返回結果都不一樣，會導致資料的不一致性）；

ROW記錄的是行更改情況，因為記錄的是行資料的修改，所以可以很好地解決上面STATEMENT的缺陷（某些情況下，ROW也有不好的地方，比如一些批量的sql語句，如果使用STATEMENT的方式，同步記錄的只有一條語句，但是基於ROW的就可能包含了大量的行記錄變更資訊）;

MIXED則代表預設情況下使用STATEMENT記錄，但在某些情況下使用ROW格式記錄，比如使用一些執行結果跟當前執行伺服器有關的，好像之前說的uuid，rand等。
binlog-format是動態引數，可以在執行中修改。bin log檔案記錄的是二進位制資料，不便於觀察，但是MySQL提供了一個叫 mysqlbinlog的工具可以翻譯bin log日誌內容。

三、pid檔案
當MySQL例項啟動時，會將自己的程序id寫入一個檔案中，該檔案即為pid檔案，具體如下圖所示

四、結構檔案
不同的儲存引擎會有不同的檔案，但是MySQL都會有一個 表名.frm 的檔案，這個檔案記錄了該表名的結構定義，下面介紹跟InnoDB相關的檔案。

表空間檔案
InnoDB採用將儲存的資料按表空間（tablespace）進行存放的設計。在預設配置下會有一個初始化大小為10MB，名為ibdata1的檔案，該檔案就是預設的表空間。可以通過設定 innodb_data_file_path 引數來指定多個檔案來組成表空間，比如可以把多個檔案分佈在不同的磁碟，以提升資料庫效能等。

使用者可以使用 innodb_file_per_table 引數設定每個基於InnoDB的表都對應一個獨立的存放空間，表名.idb。需要注意的是，就算設定了 innodb_file_per_table，這些單獨的表空間檔案只儲存了該表的資料、索引和插入緩衝BITMAP等資訊，其餘資訊還是存放在預設的表空間中。

重做日誌檔案
在預設情況下，InnoDB引擎會有兩個名為ib_logfile0、ib_logfile1的檔案，這兩個就是重做日誌檔案（redo log），記錄的是事務日誌。每個InnoDB引擎至少有一個重做日誌檔案組（group），每個檔案組下面至少有2個日誌檔案，預設是ib_logfile0，ib_logfile1，在日誌組中每個重做日誌檔案的大小都是一致的，並以迴圈寫入的方式執行。

下面列出幾個跟重做日誌有關的引數：
innodb_log_file_size：指定每個重做日誌檔案最大值
innodb_log_files_in_group：指定每個檔案組內日誌檔案的個數，預設是2個
innodb_log_group_home_dir：指定日誌檔案在MySQL資料目錄的目錄名，預設是./

重做日誌與二進位制日誌的區別
首先，二進位制日誌記錄的是所有與MySQL資料庫有關的日誌記錄，包括InnoDB、MyISAM、Heap等其他引擎的日誌；而重做日誌只記錄InnoDB引擎有關的事務日誌。
其次，記錄的內容不同，二進位制記錄的是事務具體的操作內容；而重做日誌記錄的是每個頁的更改的物理情況。
此外，寫入時間也不同，二進位制日誌僅在事務提交前進行提交，即只寫磁碟一次，無論這時該事務多大；而事務進行過程中，卻不斷有重做日誌條目被寫入日誌檔案中。

之前也說過，重做日誌不會直接寫入磁碟，而是先寫入重做日誌緩衝（redo log buffer），然後按照一定的條件順序地寫入日誌檔案。重做日誌寫入磁碟時，是按512個位元組也就是一個扇區進行寫入，因為扇區是寫入的最小單位，可以保證寫入要麼是成功的，要麼是失敗不會出現部分寫入的情況。
至於寫入的條件則是由 innodb_flush_log_at_trx_commit 控制，有效值是0，1，2，預設是1。
0 代表提交事務時，並不將事務的重做日誌寫入磁碟上的日誌檔案，而是等待主執行緒每秒的重新整理；
1 代表在執行commit事務提交時，把重做日誌緩衝同步寫入磁碟；
2 代表在執行commit事務提交時，把重做日誌非同步寫到磁碟，即寫到檔案系統快取中，不能完全保證能夠最終寫入磁碟。

想要獲得更多技術乾貨，歡迎關注睿江雲端計算公眾號。睿江雲充一送一充送活動火熱進行中~

點選連結檢視優惠：http://www.eflycloud.com/#/home?from=RJ0027&salesID=XKKHRTRBK