MySQL 日誌(錯誤日誌、二進制日誌、查詢日誌、慢查詢日誌)

MySQL 中有 4 中不一樣的日誌，分別是錯誤日誌、二進制日誌（binlog 日誌）、查詢日誌和，慢查詢日誌，應該充分利用這些日誌對數據庫進行各類維護和調優。

1、錯誤日誌

錯誤日誌時 MySQL 中最重要的日誌之一，它記錄了當 mysqld 啓動和中止時，以及服務器在運行過程當中發生任何嚴重錯誤時的相關信息。當數據庫出現任何故障致使沒法正常使用時，能夠首先查看此日誌。

2、二進制日誌

二進制日誌（binlog） 記錄了全部 DDL 語句和 DML 語句，可是不包括數據查詢語句。語句以「事件」的形式保存，它描述了數據的更改過程。此日誌對於災難時的數據恢復起着極其重要的做用。

1. 日誌的位置和格式

當用 --log-bin[=file_name] 選項啓動時，mysqld 開始將數據變動狀況寫入日誌文件。若是滅有給出 file_name 值，默認名爲主機名後面跟「-bin」。若是給出了文件名，但沒有包含路徑，則文件默認被寫入參數 datadir（數據目錄）指定的目錄。

二進制日誌的格式分爲 3 種：statement、row、mixed，能夠在啓動時經過參數 --binlog_format 進行設置，這 3 種格式的區別以下：

STATEMENT

mysql 5.1 以前的版本都採用這種方式，日誌中記錄的都是語句（statement），每一條對數據形成修改的sql語句都會記錄到日誌中，經過 mysqlbinlog 工具，能夠清晰的看到每條語句的文本。主從複製時，從庫(slave)會將日誌解析爲原文本，並在從庫中從新執行一次。這種格式的優勢的日誌記錄清晰易讀，日誌量少，對 I/O 影響較小。缺點是在某些狀況下 slave 的日誌複製會出錯。

ROW

mysql 5.1.11 以後，出現了這種新的日誌格式，它將每一行的變動記錄到日誌中，而不是記錄sql語句，好比一個簡單的跟新sql：
update emp set name='abc'
若是是 statement 格式，日誌中會記錄一行 sql 文本；
若是是 row 格式，因爲是對全表進行更新，也就是每一行記錄都會發生改變，若是是一個 100 萬行的大表，則日誌中會記錄 100萬條記錄的變化狀況。日誌量大大增長。

這種格式的優勢是會記錄每一行數據變化的細節，不會出現某些狀況下沒法複製的狀況，缺點是日誌量大，對 I/O 影響較大。

MIXED

這是目前 MySQL 默認的日誌格式，即混合了 statement 和 row 兩種日誌。默認狀況下采用 statement，但在一些特殊狀況下采用 row 來進行記錄，好比
採用 NDB 存儲引擎，此時對錶的 DML 語句所有采用 row；
客戶端使用了臨時表；
客戶端採用了不肯定函數，好比 current_user() 等；

由於這種不肯定函數在主從中獲得的值可能不一樣，致使主從數據產生不一致。mixed 格式能儘可能利用兩種模式的優勢，而避開他們的缺點。

注意：能夠在 global 和 session 級別對 binlog_format 進行日誌格式設置，但必定要謹慎操做，確保從庫的複製可以正常進行。

2. 日誌的讀取

因爲日誌以二進制方式存儲，不能直接讀取，須要用 mysqlbinlog 工具來查看，對於 statement 格式的文件能夠用工具直接查看，對於 row 格式的要加 -v 或 -vv 參數進行讀取。

3. 日誌的刪除

對於比較繁忙的系統，天天產生大量日誌，這些日誌若是長時間不清除，將會對磁盤空間帶來極大的浪費，所以，須要按期刪除日誌。

(1) 刪除全部日誌

執行 「reset master;」 命令將刪除全部 binlog 日誌，新日誌編號從「000001」開始

(2) 刪除指定序號以前的日誌文件

執行 「purge master logs to 'mysql-bin.'」命令，將刪除編號以前的全部日誌(不刪除命令中指定的文件)

(3) 刪除指定日期前的日誌

執行 「purge master log before 'yyyy-mm-dd hh24:mi:ss'」 命令將刪除指定日期前的全部日誌

(4) 修改配置文件，自動刪除

在配置文件的[mysqld]中設置參數 expire_logs_days=#, 此參數的含義是設置日誌的過時天數，過了指定的天數後日志將會被自動刪除。

4. 其餘選項

二進制日誌記錄了數據的變化過程，對於數據的完整性和安全性起着很是重要的做用。所以，MySQL 還提供了一些其餘參數選項來進行更小粒度的管理

--binlog-do-db=db_name

該選項告訴主服務器，若是當前的數據庫（即 use 選定的數據庫）是 db_name, 應將更新記錄到二進制文件中，其餘全部麼有顯式指定的數據庫更新將被忽略，不記錄在日誌中。

--binlog-ignore-db=db_name

該選項告訴主服務器，若是當前的數據庫(即 use 選定的數據庫) 是 db_name,不該將更新保存到二進制日誌中，其餘沒有顯式忽略的數據庫都將進行記錄。
若是想記錄或忽略多個數據庫，能夠對上面兩個選項分別使用屢次。

--innodb-safe-binlog

此選項常常和 --sync-binlog = N （每寫 N 第二天志同步磁盤）一塊兒配合使用，使得事務在日誌中的記錄更加安全。

3、查詢日誌

查詢日誌記錄了客戶端的全部語句，而二進制日誌不包含只查詢數據的語句。

1. 日誌的位置和格式

查詢日誌和慢查詢日誌均可以選擇保存在文件或者表中，使用參數 --log-output[=value]來進行控制，value 值能夠是table、file、none 的一個或者多個組合，中間用逗號進行分割，分別表示日誌保存在表、文件、不保存在表和文件中，這裏的表指的是 mysql 庫中的 general_log (慢查詢日誌是 slow_log) 表。
其中 none 的優先級最高，好比：
--log-output = table, file 表示日誌能夠同時輸出到表和文件中
--log-output = table, none 因爲 none 的優先級高，表示日誌不保存在表和文件中。
若是不顯示設置此參數，則默認輸出到文件。

能夠經過參數 --general_log[={0|1}] 和 --general_log_file=file_name 來進行控制。
--general_log 設置爲1或者不帶值均可以啓用查詢日誌；設置爲0表示關閉查詢日誌，若是不指定此參數也不會啓用。
若是沒有指定 --general_log_file=file_name 的值，且沒有顯式設置 --log-output 參數，那麼日誌將寫入參數 datadir(數據目錄)指定的路徑下，默認文件名爲 host_name.log。

這兩個參數都是 global 類型，能夠在系統啓動時或者系統運行時進行動態修改，若是想在 session 級別控制，則經過在 session 中設置參數 sql_log_off 爲 on 或者 off。

2. 日誌的讀取

查詢日誌記錄的格式是純文本，因此能夠直接進行讀取。

注意： log 日誌中記錄了全部數據庫的操做，對於訪問頻繁的系統，此日誌對系統性能的影響較大，建議通常狀況下關閉。

4、 慢查詢日誌

慢查詢日誌記錄了全部執行時間超過參數 long_query_time(單位:秒)設置值而且掃描記錄數不小於 min_examined_row_limit 的全部 sql 語句的日誌(注意：得到表鎖定的時間不算做執行時間)。long_query_time 默認爲 10 秒，最小爲 0，精度能夠到微秒。

在默認狀況下，有兩類常見語句不會記錄到慢查詢日誌：管理語句和不使用索引進行查詢的語句。管理語句包括 alter table、analyze table、check table、create index、drop index、optimize table、repair table。若是要監控這兩類 sql語句，能夠分別經過設置參數
--log-slow-admin-statements 和 log_queries_not_using_indexes 進行控制。

1. 文件位置和格式

經過如下兩個參數開啓慢查詢日誌：

(1) --slow_query_log[={0|1}]

若是不指定值或者指定值爲 1 都會打開慢查詢；

(2) --slow_query_log_file[=file_name]

指定慢查詢日誌的路徑

注意： 可使用 --log-output 參數來指定日誌的輸出方式，默認會輸出到文件，固然也能夠選擇輸出到表，須要注意的是，若是選擇輸出到表，則表中的記錄只能精確到秒，而日誌文件中能夠精確到微秒。

2. 日誌的讀取

和錯誤日誌、查詢日誌同樣，慢查詢日誌記錄的格式也是純文本，能夠被直接讀取。
若是要設置微秒級的慢查詢，能夠 set global long_query_time=0.01

若是慢查詢日誌中記錄內容不少，可使用 mysqldumpslow 工具對慢查詢日誌進行分類彙總。對於 sql 文本徹底一致，只是變量不一樣的語句，mysqldumpslow 將會自動視爲同一個語句進行統計，變量值用 N 來代替。這個統計結果將大大增長用戶閱讀慢查詢日誌的效率，迅速定位系統的 sql 瓶頸。

注意： 慢查詢日誌對於發現應用中有性能問題的 sql 頗有幫助，正常狀況下，打開此日誌並常常查看分析。