在這篇文章里我將討論一個相關的主題 – InnoDB 事務隔離模式，還有它們與MVCC（多版本并發控制）的關系，以及它們是如何影響MySQL性能的。

MySQL手冊提供了一個關于MySQL支持的事務隔離模式的恰當描述 – 在這里我并不會再重復，而是聚焦到對性能的影響上。

SERIALIZABLE – 這是最強的隔離模式，本質上打敗了在鎖管理（設置鎖是很昂貴的）的條件下，多版本控制對所有選擇進行鎖定造成大量的開銷，還有你得到的并發。這個模式僅在MySQL應用中非常特殊的情況下使用。

REPEATABLE READ – 這是默認的隔離級別，通常它是相當不錯的，對應用程序的便捷性來說也不錯。它在第一次的時候讀入所有數據 （假設使用標準的非鎖讀）。但是這有很高的代價 – InnoDB需要去維護事務記錄，從一開始就要記錄，它的代價是非常昂貴的。更為嚴重的情況是，程序頻繁地更新和hot rows – 你真的就不想InnoDB去處理rows了，它有成百上千個版本。

在性能上的影響， 讀和寫都能夠被影響。用select查詢遍歷多個行是代價高昂的，對于更新（update）也是，在MySQL 5.6中，尤其是版本控制看起來導致了嚴重的爭用問題。

下面是例子：完全在內存中的數據集中運行 sysbench，并啟動 transaction 、運行全表、掃描、查詢幾次，同時保持 transaction 是開著的：

sysbench --num-threads=64 --report-interval=10 --max-time=0 --max-requests=0 --rand-type=pareto --oltp-table-size=80000000 --mysql-user=root --mysql-password= --mysql-db=sbinnodb --test=/usr/share/doc/sysbench/tests/db/update_index.lua run

如果有人想測試，可以重復下面我用的查詢集合：
 

不只是可復讀（Repeatable Read）的默認隔離級別，同樣也可以用于InnoDB 邏輯備份 –  mydumper 或者 mysqldump –single-transaction

這些結果顯示這個備份的方法恢復的時間太長而不能用于大型數據集合，同樣這個方法受到性能影響，也不能用于頻繁寫入（write ）的環境中。

READ COMMITTED 模式和REPEATABLE READ模式很相似，本質區別在于哪個版本都不在transaction中從頭開始讀取，取而代之的從當前語句開始讀取。因此使用這種模式允許InnoDB少維護很多版本，特別是你沒有很長的statements要允運行。如果你有很長的select要運行，如報表查詢對性能的影響仍然很嚴重。