1. 引數檔案
MySQL實體啟動時，資料庫會先讀取引數檔案，用來尋找資料庫的各種檔案所在位置以及指定某些初始化引數，與Oracle資料庫不同的是，如果沒有配置引數檔案，MySQL啟動時，會加載默認值，
靜態引數是只讀的，動態引數可以在MySQL實體運行中進行更改，其修改范圍可以參考MySQL官方手冊中 Dynamics System Variables相關內容，
2. 日志檔案
2.1 錯誤日志（error log）
該檔案記錄了所有的錯誤資訊，也記錄了一些警告資訊和正確資訊，可以通過命令 SHOW VARIABLES LIKE 'log_error' 來定位該檔案
2.2 慢查詢日志（slow query log）
可以在MySQL啟動時設一個閾值（long_query_time = 10000ms），將運行時間超過該值的所有SQL陳述句都記錄到慢查詢日志中，如果運行的SQL陳述句沒有使用索引（log_throttle_queries_not_using_indexes，每分鐘未使用索引的SQL陳述句多少次后加入慢查詢日志），也會被加入到慢查詢日志中，
2.3 二進制日志（binlog）
二進制日志記錄了對MySQL資料庫執行更改的所有操作（不包括SELECT SHOW等操作），主要有以下幾種作用：
- 恢復（recovery） 通過二進制日志進行point-in-time 的恢復 （第八章介紹）
- 復制（replication）通過復制和執行二進制日志使一臺遠程的MySQL資料庫（一般為slave）與一臺MySQL資料庫（master）進行實時同步，
- 審計（audit） 用戶可以通過二進制日志中的資訊來進行審計，判斷是否有對資料庫進行注入的攻擊，
引數sync_binlog = [N]表示每寫緩沖多少次就同步到磁盤（所有未提交的二進制日志會被記錄到一個快取中去，等事務提交時，直接將快取中的二進制日志寫入二進制日志檔案），若N為1，表示采用同步寫磁盤的方式來寫二進制日志（如果不是同步寫的，資料庫宕機時，可能最后一部分資料沒有寫入二進制日志檔案中），但是設為1，還是有一種情況導致問題發生，當使用InnoDB存盤引擎時，在一個事務發出COMMIT動作之前，由于sync_binlog為1，因此將二進制日志立即寫入磁盤中，如果這時寫入了二進制日志，但是還未提交日志，發生了宕機，那么在MySQL資料庫下次啟動時，由于COMMIT操作并沒有發生，這個事務應該被回滾掉，但是二進制日志已經記錄了該事務資訊，所以不能被回滾，通過設定引數innodb_support_xa為1來解決，該引數確保二進制日志和InnoDB存盤引擎資料檔案的同步，
binlog_format 引數設定二進制檔案的格式：
- STATEMENT 二進制日志檔案記錄的是邏輯SQL陳述句
- ROW 二進制日志檔案記錄的是表中行的更改情況（檔案相應更大）
- MIXED
2.4 查詢日志（log）
記錄了所有對MySQL資料庫請求的資訊，無論這些資訊是否得到了正確的執行，
3. InnoDB存盤引擎檔案
3.1 表空間檔案
InnoDB將存盤的資料按表空間（tablespace）進行存放，
3.2 重做日志檔案（redo log）
每個InnoDB存盤引擎至少有1個重做日志檔案組，每個檔案組下至少有兩個重做日志檔案，如默認的ib_logfile0和ib_logfile1，為了獲得更高的可靠性，用戶可以設定多個鏡像日志組，將不同的檔案組放在不同的磁盤上，以此提高重做日志的高可用性，在日志組中，每個重做日志檔案的大小一致，并以回圈寫入的方式運行，從重做日志緩沖往磁盤寫入時，是按512位元組，也就是一個扇區的大小進行寫入，因為扇區是寫入的最小單位，所以重做日志的寫入程序不需要doublewrite，
重做日志和二進制日志的區別？
由binlog 和redo log的區別可知：binlog日志只用于歸檔，只依靠 binlog 是沒有crash-safe 能力的，但只有 redo log 也不行，因為 redo log 是 InnoDB特有的，且日志上的記錄寫入磁盤后會被覆寫掉，因此需要 binlog 和 redo log 二者同時記錄，才能保證當資料庫發生宕機重啟時，資料不會丟失，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/296135.html
標籤：其他
上一篇：第二章 InnoDB 存盤引擎
下一篇：第四章 表 （學習筆記）