MySQL binlog日志三種模式選擇及配置
在認識binlog日志三種模式前，先了解一下解析binlog日志的命令工mysqlbinlog。mysqlbinlog工具的作用是解析mysql的二進制binlog日志內容，把二進制日志解析成可以在MySQL數據庫里執行的SQL語句。binlog日志原始數據是以二進制形式存在的，需要使用mysqlbinlog工具轉換成SQL語句形式。
mysql的binlog日志作用是用來記錄mysql內部增刪改等對mysql數據庫有更新內容的記錄（對數據庫進行改動的操作），對數據庫查詢的語句如show，select開頭的語句，不會被binlog日志記錄，主要用于數據庫的主從復制與及增量恢復。
案例：
在對數據庫進行定時備份時，只能備份到某個時間點，假如在凌晨0點進行全備了，但是在中午12點出現故障需要恢復數據，使用0點的全備只能恢復到0點時刻的數據，難道0點到12點的數據只能丟失了嗎？
這時就是體現binlog日志重要性的時候了，需要對binlog日志進行定時推送（一分鐘一次或五分鐘一次，時間頻率視業務場景而定）完成增量備份。當出現故障時，可以使用定時備份和增量備份恢復到故障點時刻的數據。具體的恢復方案，這里不做簡述，后面再寫文章來講解。
binlog日志三種模式
ROW Level
記錄的方式是行，即如果批量修改數據，記錄的不是批量修改的SQL語句事件，而是每條記錄被更改的SQL語句，因此，ROW模式的binlog日志文件會變得很“重”。
優點：row level的binlog日志內容會非常清楚的記錄下每一行數據被修改的細節。而且不會出現某些特定情況下存儲過程或function，以及trigger的調用和觸發器無法被正確復制的問題。
缺點：row level下，所有執行的語句當記錄到日志中的時候，都以每行記錄的修改來記錄，這樣可能會產生大量的日志內容，產生的binlog日志量是驚人的。批量修改幾百萬條數據，那么記錄幾百萬行……
Statement level(默認)
記錄每一條修改數據的SQL語句（批量修改時，記錄的不是單條SQL語句，而是批量修改的SQL語句事件）?？瓷厦娴膱D解可以很好的理解row level和statement level兩種模式的區別。
優點：statement模式記錄的更改的SQ語句事件，并非每條更改記錄，所以大大減少了binlog日志量，節約磁盤IO，提高性能。
缺點：statement level下對一些特殊功能的復制效果不是很好，比如：函數、存儲過程的復制。由于row level是基于每一行的變化來記錄的，所以不會出現類似問題
Mixed
實際上就是前兩種模式的結合。在Mixed模式下，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日志形式，也就是在Statement和Row之間選擇一種。
企業場景如何選擇binlog的模式
1、 如果生產中使用MySQL的特殊功能相對少（存儲過程、觸發器、函數）。選擇默認的語句模式，Statement Level。
2、 如果生產中使用MySQL的特殊功能較多的，可以選擇Mixed模式。
3、 如果生產中使用MySQL的特殊功能較多，又希望數據***化一致，此時***Row level模式；但是要注意，該模式的binlog非常“沉重”。
查看binlog模式
- mysql> show global variables like "%binlog_format%";
- +---------------+-----------+
- | Variable_name | Value |
- +---------------+-----------+
- | binlog_format | STATEMENT |
- +---------------+-----------+
配置binlog日志模式
vim my.cnf（在[mysqld]模塊中配置）
- log-bin = /data/3306/mysql-bin
- binlog_format="STATEMENT"
- #binlog_format="ROW"
- #binlog_format="MIXED"
不重啟，使配置在msyql中生效
SET global binlog_format='STATEMENT';
