## **Mysql binlog 日志有三種格式：** * Statement：語句 * MIXED：混合 * ROW：行 ***** ## **查看當前模式：** ``` show variables like '% format%'; ```  ## **如需更改模式：** vim my.cnf（在[mysqld] 模塊中配置） ``` binlog_format=STATEMENT binlog_format=ROW binlog_format=MIXED ``` ***** ## **詳細解釋：** 1. row level 模式： 日志中會記錄成每一行數據的修改，然后在 slave 端再對相 同的數據進行修改。 **優點：** bin‐log 中可以不記錄執行的 sql 語句的上下文相關的 信息，僅僅只需要記錄哪一條記錄被修改了，修改成什么樣 了。所以 row level 的日志的內容會非常清楚的記錄下每一行 數據修改的細節。 **缺點：** row level 下，所有的執行的語句當記錄到日志中的時 候，都將以每行記錄的修改記錄，這樣可能會產生大量的日 志內容，比如有這樣一條 update 語句：update product set owner\_member\_id='d',執行之后，日志中記錄的不是這條 update 語句所對應的 event 事件(mysql 是以事件的形式來記 錄 bin‐log 日志)，而是這條語句所更新的每一條記錄的變化 情況，這樣就記錄了很多條記錄被更新的事件。因此，bin‐log 日志的量會很大。 ***** 2. statement level 模式 每一條修改數據的 sql 都會記錄到 master 的 bin‐log 中。slave 在復制的時候 sql 進程會解析成和原來 master 端執行過的相 同的 sql 來再次執行。 **優點：** statement level 下的優點，首先就是解決了 row level 下的缺點，不需要記錄每一行數據的變化，減少 bin‐log 日志 量，節約 io，提高性能。因為他只需要記錄在 master 上所執 繁星老師作品 繁星老師作品 行的語句的細節，以及執行語句時候的上下文的信息。 **缺點：** 由于它是記錄的執行語句，所以為了讓這些語句在 slave 端也能正確執行，那么他還必須記錄每條語句在執行的 時候的一些相關信息，也就是上下文信息，以保證所有語句 在 slave 端被執行的時候能夠得到和在 master 端執行時候相 同的結果。另外就是,由于 mysql 現在發展比較快，很多的新 功能加入，使 mysql 的復制遇到了不小的挑戰,自然復制的時 候涉及到越復雜的內容，bug 也就越容易出現。在 statement level 下，目前已經發現的就有不少情況會造成 mysql 的復制 問題，主要是修改數據的時候使用了某些特定的函數或者功 能的時候會出現，比如 sleep()在有些版本就不能正確復制。 ***** 3. mixed 模式 實際上就是前兩種模式的結合，在 mixed 模式下，mysql 會 根據執行的每一條具體的 sql 語句來區分對待記錄的日志形 式，也就是在 statement 和 row 之間選一種。新版本中的 statement level 還是和以前一樣，僅僅記錄執行的語句。而 新版本的 mysql 中對 row level 模式被做了優化，并不是所有 的修改都會以 row level 來記錄，像遇到表結構變更的時候就 會以 statement 模式來記錄，如果 sql 語句確實就是 update 或者 delete 等修改數據的語句，那么還是會記錄所有行的變更。 ***** ## **查看 binlog日志內容：** ``` // 去掉里面加密密文：‐‐base64‐output=DECODE‐ROWS mysqlbinlog? mysql‐bin.000002 –v ```