測試環境及名詞解釋：
操作系統：CentOS release 5.5 (Final)
MySQL版本：5.1.40-community-log
InnoDB版本：build-in
測試的事務隔離級別：Read-committed(以下簡稱：RC)、Repeatable-read(以下簡稱：RR)、日志登記選項(簡稱：LBO)、STATEMENT-based logging(簡稱：LBS)、ROW-based format(簡稱：LBR)
基於日志復制模式(簡稱：RBO)：STATEMENT、ROW、MIXED
事務隔離級別和日志模式組合的分析和總結：
■ 事務隔離級別為：Read-committed(簡稱：RC)
事務安全性：不支持對InnoDB引擎表作DML(DML指：INSERT、UPDATE、DELETE)，但是允許對非事務引擎表的數據進行一切操作；
事務性能：不支持對事務引擎InnoDB表進行操作；
● RC與 STATEMENT配置組合
日志記錄格式：所有的變更操作都以基於命令方式登記二進制日志(簡稱：LBS)；
復制安全性：對於SQL語句中，若存在不確定性的函數，則數據復制存在一致性；
IO量：無增加；
● RC與 MIXED配置組合
事務安全性：結合InnoDB提供的MVCC功能，可以做到只看見已經提交事務修改後的數據，但是無法確保同一事務內，同一個查詢語句二次執行，獲得的記錄集相同；
事務性能：會比不提交讀隔離級別性能低，但比可重復讀隔離級別性能高；
日志記錄格式：所有的變更操作都以基於行模式登記二進制日志(簡稱：LBR)；
復制安全性：能做到主備數據復制的一致性；
IO量：所有的DML操作都將轉化成基於行模式登記二進制日志，那麼會增加大量物理寫IO；
● RC與 ROW配置組合
若是事務隔離級別設置為：Read-committed(以下簡稱：RC)，那麼無論日志模式(注：binlog_format)設置為：MIXED 或者 ROW，二進制日志都將以ROW模式登記，為此與RC+MIXED配置組合相同，不贅述。
■ 事務隔離級別為：Repeatable-read(簡稱：RR)
事務安全性：在RC隔離級別優點的基礎之上，做到了同一個事務內，同一個查詢請求，多次執行，獲得的記錄集一定相同；
事務性能：比RC事務隔離級別消耗的資源更多一些，也即性能低一些，但比Seriailizable隔離級別的性能好；
● RR與 STATEMENT配置組合
日志記錄格式：基於命令行模式登記二進制日志(簡稱：LBS);
復制安全性：對於SQL語句中，若存在不確定性的函數，則數據復制存在一致性;
IO量：無增加;
● RR與 MIXED配置組合
日志記錄格式：對於SQL語句中無不確定性函數的DML操作，則會基於命令行模式登記二進制日志(簡稱：LBS);但是對於包含不確定性函數的DML操作，則一定會使用基於行模式登記二進制日志(簡稱：LBR)；
復制安全性：能確保數據復制的正確性；
IO量：相比STATEMENT可能會增加，但是否增加二進制的量，主要看編寫的SQL語句，是否包含一些不確定性的函數;
● RR與 ROW配置組合
日志記錄格式：對於所有的DML操作，都采用基於行的模式登記二進制日志;
復制安全性：能確保數據復制的正確性;
IO量：全采用基於行的模式登記二進制日志，將明顯增加物理IO;
事務隔離級別和日志模式組合適用的場景闡述：
● RC與 STATEMENT配置組合
結合上述的分析和總結，提交讀+基於命令行模式。首先是跑事務引擎的MySQLd服務，不支持此組合模式，那麼其適合場景：
1>.使用非事務引擎存儲數據、支撐業務，不使用事務引擎 (一般指：InnoDB引擎);
2>.不需要使用到MySQL復制的架構，或者SQL語句確定不包含不確定性函數等內容;
● RC與 MIXED配置組合
1>.允許事務中，存在同一個SQL查詢語句多次執行獲得的記錄集不同，或者規避此類業務;
2>.讀操作量遠遠大於寫操作的業務場景;
3>.不需要打開二進制日志功能的業務場景;
● RC與 ROW配置組合
對於事務隔離級別：RC，無論binlog_format設置為：MIXED 還是 ROW，其二進制日志登記模式都一樣，所以其適合場景與RC與 MIXED配置組合一樣。
● RR與 STATEMENT配置組合
1>.需要確保事務中，同一個SQL查詢語句多次執行獲得的記錄集相同的業務場景;
2>.不需要關心讀寫比例的業務場景;
3>.不使用MySQL的復制功能，或者DML操作SQL確保不存在不確定性的內容;
● RR與 MIXED配置組合
1>.需要確保事務中，同一個SQL查詢語句多次執行獲得的記錄集相同的業務場景;
2>.需要使用MySQL的復制功能，且不想關心 DML操作類SQL語句是否存在不確定性的內容;
3>.更新操作量還是比較多，且想減少登記二進制日志而增加的物理IO，以及加速MySQL復制的速度;
● RR與 ROW配置組合
1>.需要確保事務中，同一個SQL查詢語句多次執行獲得的記錄集相同的業務場景;
2>.需要使用MySQL的復制功能，且不想關心 DML操作類SQL語句是否存在不確定性的內容;
3>.以讀為主的業務，更新量較少且從設計上規避行模式登記日志缺陷的業務場景;
推薦組合模式：
若需要打開二進制日志功能，且需要使用MySQL復制，但業務是以讀為主，且更新量為主的表，被設計成非常輕小型，也不想嚴格關心SQL寫法。例如：常更新的字段放一起且最好是整形的，不常更新的字段存放一起，一定無大字段(注釋：TEXT、BLOB等)。那麼可以考慮使用：RC+MIXED組合模式。
若需要打開二進制日志功能，且需要使用MySQL復制，但業務的讀寫量相差不大，且不想為規避登記二進制日志的問題而設計表，也不想嚴格關心SQL寫法，那麼建議使用：RR+MIXED組合模式。
當然對於不需要打開二進制日志功能的業務，那選擇就容易，關鍵在選擇事務隔離級別為：RC還是RR的問題，為事務安全性角度出發，選擇：RR，為從事務消耗資源，也即性能出發，選擇：RC。
為方便大家閱讀，以及適應快餐式文化氛圍，文章開頭特意先寫對比、分析和結論，那麼接下來將把測試過程，以及一些對比信息告訴大家，建議一線技術人員一定要看下測試過程.測試過程，也是分設置不同事務隔離級別tx_isolation的值，配合設置不同binlog_format的值，然後執行數據的更新語句，再使用MySQLbinlog工具解讀二進制日志文件的內容。
測試用例：
● 測試表的數據
備注: 測試過程中,更新ID=1 和 ID=4 的紀錄。
● 用於測試的SQL
測試對比信息過程：
● RC與 STATEMENT配置組合
MySQL 5.1系列設置 RC+STATEMENT組合的模式，無法對支持事務的InnoDB引擎作數據更新操作，為此我們在實際的生產環境中無法使用，當然若關閉MySQL的二進制日志登記功能是可以的，或者打開允許不安全模式登記二進制日志的參數，也是可以的。
● RC與 MIXED配置組合
事務隔離級別、日志模式、執行的SQL信息：
緊接著我們翻譯二進制日志信息，看下二進制日志中登記的內容是啥?
1>.1號SQL對應的二進制日志信息
我們只修改了TIMESTAMP類型字段字段：alterDate的值，其他值都沒有變化，但是都被記錄到二進制日志中，而且在WHERE 和SET 部分都有出現。
2>.3號SQL語句對應的二進制日志信息
備注：
編號為：3的SQL語句中使用了范圍條件更新日期的方式，並且日期值也特意加入了隨機函數，但從二進制日志中，我們可以發現，都是固定的值和只登記了更新到的記錄內容。
對於其他SQL更新產生的內容也是類似的，其他3條SQL語句執行後，在二進制日志文件中登記的內容，讀者們可以自己使用：MySQLbinlog –v –v 二進制日志文件 方式查看，節省點篇幅，文章後面我們總結日志記錄特點。
● RC與ROW配置組合
我們從RC+MIXED配置組合測試的內容，可以看到其全部轉換成了行模式登記二進制日志文件內容，那麼此模式就沒有多闡述的地方，我們錯開的方式，察看下編號為：4的SQL二進制日志信息，如圖：
備注：
編號為4的SQL中涉及不確定性函數：UUID()，WHERE條件為：范圍掃描，真實記錄的二進制日志內容，都是固定的字段屬性值，和真實被更新到的記錄。
● RR與 STATEMENT配置組合
請讀者注意標注紅線的地方，對於存在隨機數函數，以及不確定性的UUID函數，二進制日志文件都是原樣登記的，含有這些不確定性函數的SQL再次執行，將無法獲得相同的值，這會給MySQL的復制帶來麻煩，以及使用二進制日志進行數據恢復的時候。
● RR與 MIXED配置組合
此部分我們重點看2部分的日志，一部分是選擇以命令行模式登記的二進制日志，另外一類是選擇以行模式登記的二進制日志，第一類，如圖：
請讀者再回味下上一個節點：RR+STATEMENT組合產生的二進制日志，對比我們會發現，其都是以基於命令行模式，但是RR+MIXED組合配置，則增加了一些內容，例如圖中紅色字段部分，為使大家看得更詳細，關於如何處理隨機函數的問題，以確保在二進制日志用於恢復的時候，確保SQL產生的記錄值是永恆固定的，再單獨截圖一張：
接下來我們再看下，對於無法通過添加類似Oracle的hint內容，解決不確定性函數登記到二進制日志文件中的問題，先看二進制日志截圖：
對於MySQLd沒有支持或無法通過添加類似hint模式解決的不確定性問題，RR+MIXED模式下，二進制日志登記將會以行模式登記二進制日志，而解決不確定性問題。
● RR與 ROW配置組合
對於RR+ROW組合配置，所有DML操作的SQL日志都是以基於行模式登記，為此我們只看編號為：1、4兩條SQL的二進制日志內容，編號為1的SQL對應的二進制日志內容，如圖：
接下來我們再看下編號為：4的SQL對應的二進制日志內容，如圖：
通過閱讀翻譯後的二進制日志詳細內容，以及對比不同事務隔離級別和binlog_format配置組合情況下，登記的二進制日志， 我們可以分析、總結出如下內容：
● 二進制日志文件中，表結構中字段名成都是用@符號，加數字編號的模式，且是按字段先後順序編號的方式，此地方就是一個風險點，尤其雙主復制模式下，後續篇章講解復制存在的風險點詳細告訴大家;
● RC模式下對事務引擎：InnoDB是全部采用行模式記錄二進制日志;
● 行模式登記二進制日志時，字段的原內容是全部出現在：WHERE部分，需要被修改後的內容全部顯示在：SET部分，為此若表字段多或有大字段，對數據做變更之時，產生的二進制日志內容將會很大，從而消耗大量系統的物理IO資源;
● 行模式登記二進制日志時，對於字段值更新的SQL中不確定性的內容，將會替換為確定性的值登記到二進制日志文件中;
● 行模式登記二進制日志時，若DML操作SQL語句，使用了范圍條件，而登記到二進制日志中的內容，是實際更新的條數詳細內容，此模式也會增加大量二進制日志的容量;
● 行模式登記二進制日志時，若是表有大字段或者某個表字段很多，那麼產生的二進制日志容量就會非常大了，意味著消耗系統的物理IO資源將會急劇增加;
● Binlog_format設置為：MIXED,對於二進制日志以基於命令行模式 還是 基於行模式登記，取決於：事務隔離級別和所涉及的SQL共同決定，但是對於RC事務隔離級別，就無論什麼類型的DML操作SQL，都以行模式登記;
● 事務隔離級別為：RC情況下，binlog_format設置為MIXED還是為ROW，對於二進制日志登記而言都是一樣的，以行模式登記二進制日志。
● 事務隔離級別為：RR情況下，binlog_format設置為MIXED，MySQLd服務會根據DML操作的SQL語句情況，決定是以行模式登記二進制日志，還是以 命令行模式登記;
● 事務隔離級別為：RR情況下，binlog_format設置為MIXED，MySQLd服務會添加類似Oracle的hint內容，解決部分不確定性函數而帶來的SQL重復執行無法獲得相同記錄值的問題;
後續：
上述為事務隔離級別+binlog_format組合模式下，不同的二進制日志登記模式，通過分析、比對了各自的優缺點，以及給出了大家什麼類型業務場景下的組合配置模式，希望幫助掌握這塊的知識點，以及能幫助大家針對自己的業務場景，可以作出正確的事務隔離級別+binlog_format配置組合選擇。
另外，對於MySQL基於三種不同復制模式情況下，登記的二進制日志的二種模式，以及基於表：是否有主鍵(或非空唯一索引)、是否有索引等組合在一起，二進制日志在登記、復制過程中應用二進制日志，其效果都是不一樣的，也並不像大家想的那樣，為此，後續會專門寫一篇文章與大家分享、探討。
