原文出自 http://www.abcdocker.com/abcdocker/213

MySQ binlog三種模式及設定方法

1.1 Row Level  行模式

日誌中會記錄每一行資料被修改的形式，然後在slave端再對相同的資料進行修改 優點：在row level模式下，bin-log中可以不記錄執行的sql語句的上下文相關的資訊，僅僅只需要記錄那一條被修改。所以rowlevel的日誌內容會非常清楚的記錄下每一行資料修改的細節。不會出現某些特定的情況下的儲存過程或function，以及trigger的呼叫和觸發無法被正確複製的問題 缺點：row level，所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，會產生大量的日誌內容。

1.2 Statement Level（預設）

每一條會修改資料的sql都會記錄到master的bin-log中。slave在複製的時候sql程序會解析成和原來master端執行過的相同的sql來再次執行 優點：statement level下的優點首先就是解決了row level下的缺點，不需要記錄每一行資料的變化，減少bin-log日誌量，節約IO，提高效能，因為它只需要在Master上鎖執行的語句的細節，以及執行語句的上下文的資訊。 缺點：由於只記錄語句，所以，在statement level下 已經發現了有不少情況會造成MySQL的複製出現問題，主要是修改資料的時候使用了某些定的函式或者功能的時候會出現。

1.3 Mixed 自動模式

在Mixed模式下，MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌格式，也就是在Statement和Row之間選擇一種。如果sql語句確實就是update或者delete等修改資料的語句，那麼還是會記錄所有行的變更。

行模式和語句模式的區別

1.語句模式： 100萬條記錄 只需1條delete * from test；就可以刪除100萬條記錄 2.row模式 100萬條記錄 記錄100萬條刪除命令

1.4 企業場景如何選擇binlog模式

1、網際網路公司，使用MySQL的功能相對少（儲存過程、觸發器、函式）     選擇預設的語句模式，Statement Level（預設）
2、公司如果用到使用MySQL的特殊功能（儲存過程、觸發器、函式）     則選擇Mixed模式
3、公司如果用到使用MySQL的特殊功能（儲存過程、觸發器、函式）又希望資料最大化一直，此時最好選擇Row level模式 行模式和語句模式的區別 1.語句模式： 100萬條記錄 只需1條delete * from test；就可以刪除100萬條記錄 2.row模式 100萬條記錄 記錄100萬條刪除命令

1.5 如何配置binlog

在資料庫中檢視binlog模式

1. [email protected] 11:28:05->show global variables like '%binlog_format%';
2. +---------------+-----------+
3. | Variable_name | Value     |
4. +---------------+-----------+
5. | binlog_format | STATEMENT |
6. +---------------+-----------+
7. 1 row in set (0.00 sec)

配置檔案引數如下：

1. [myslqd]
2. log-bin=mysql-bin
3. #binlog_format="STATEMENT"
4. #binlog_format="ROW"
5. #binlog_format="MIXED"

執行時線上修改（臨時）；

1. mysql>SET GLOBAL binlog_format = 'ROW';
2. mysql>show global variables like '%binlog_format%';
3. 其他模式命令為：
4. SET GLOBAL binlog_format = 'MIXED';
5. SET GLOBAL binlog_format = 'STATEMENT';

解釋： GLOBAL=全域性會話 SESSION=當前會話 檢驗ROW模式下binlog日誌記錄效果

1. [[email protected] 3306]# mysqlbinlog --base64-output="decode-rows" --verbose mysql-bin.000248
2. /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
3. /*!40019 SET @@session.max_insert_delayed_threads=0*/;
4. /*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
5. DELIMITER /*!*/;
6. # at 4
7. #160628 11:06:52 server id 1  end_log_pos 107   Start: binlog v 4, server v 5.5.49-log created 160628 11:06:52 at startup
8. # Warning: this binlog is either in use or was not closed properly.
9. ROLLBACK/*!*/;
10. # at 107
11. #160628 11:07:09 server id 1  end_log_pos 177   Query   thread_id=1     exec_time=0     error_code=0
12. SET TIMESTAMP=1467083229/*!*/;
13. SET @@session.pseudo_thread_id=1/*!*/;
14. SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
15. SET @@session.sql_mode=0/*!*/;
16. SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
17. /*!\C utf8 *//*!*/;
18. SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
19. SET @@session.lc_time_names=0/*!*/;
20. SET @@session.collation_database=DEFAULT/*!*/;
21. BEGIN
22. /*!*/;
23. # at 177
24. # at 223
25. #160628 11:07:09 server id 1  end_log_pos 223   Table_map: `oldboy`.`sc` mapped to number 33
26. #160628 11:07:09 server id 1  end_log_pos 785   Update_rows: table id 33 flags: STMT_END_F
27. ### UPDATE `oldboy`.`sc`
28. ### WHERE
29. ###   @1=1
30. ###   @2=1001
31. 顯示的比較詳細