# 什么是 Binlog MySQL 的二進制日志可以說 MySQL 最重要的日志了，它記錄了所有的 DDL 和 DML(除 了數據查詢語句)語句，以事件形式記錄，還包含語句所執行的消耗的時間，MySQL 的二進 制日志是事務安全型的。 一般來說開啟二進制日志大概會有 1%的性能損耗。二進制有兩個最重要的使用場景: 1. MySQL Replication 在 Master 端開啟 Binlog，Master 把它的二進制日志傳遞給 Slaves來達到 Master-Slave 數據一致的目的。 2. 自然就是數據恢復了，通過使用 MySQL Binlog 工具來使恢復數據。 # Binlog 的分類 MySQL Binlog 的格式有三種，分別是 STATEMENT,MIXED,ROW。在配置文件中可以選擇配置 binlog_format= statement|mixed|row。三種格式的區別： 1. **statement：語句級**，binlog 會記錄每次一執行寫操作的語句。相對 row 模式節省空 間，但是可能產生不一致性，比如“update tt set create_date=now()”，如果用 binlog 日志 進行恢復，由于執行時間不同可能產生的數據就不同。 優點：節省空間。 缺點：有可能造成數據不一致。 2. **row：行級**， binlog 會記錄每次操作后每行記錄的變化。 優點：保持數據的絕對一致性。因為不管 sql 是什么，引用了什么函數，他只記錄執行后的效果。 缺點：占用較大空間。 3.** mixed：statement 的升級版**，一定程度上解決了，因為一些情況而造成的 statement模式不一致問題，默認還是 statement，在某些情況下譬如：當函數中包含 UUID() 時；包含AUTO_INCREMENT 字段的表被更新時；執行 INSERT DELAYED 語句時；用 UDF 時；會按照ROW 的方式進行處理 優點：節省空間，同時兼顧了一定的一致性。 缺點：還有些極個別情況依舊會造成不一致，另外 statement 和 mixed 對于需要對binlog 的監控的情況都不方便。 **綜合上面對比，Canal 想做監控分析，選擇 row 格式比較合適。**