過去的幾個(gè)月我寫了兩篇文章，一篇是InnoDB 事務(wù)歷史相關(guān)的危險(xiǎn)債務(wù)，另一篇是關(guān)于MVCC 可能導(dǎo)致MySQL嚴(yán)重的性能問題的真相。在這篇文章里我將討論一個(gè)相關(guān)的主題 – InnoDB 事務(wù)隔離模式，還有它們與MVCC（多版本并發(fā)控制）的關(guān)系，以及它們是如何影響MySQL性能的。

　　MySQL手冊提供了一個(gè)關(guān)于MySQL支持的事務(wù)隔離模式的恰當(dāng)描述 – 在這里我并不會(huì)再重復(fù)，而是聚焦到對(duì)性能的影響上。

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

　　REPEATABLE READ – 這是默認(rèn)的隔離級(jí)別，通常它是相當(dāng)不錯(cuò)的，對(duì)應(yīng)用程序的便捷性來說也不錯(cuò)。它在第一次的時(shí)候讀入所有數(shù)據(jù) （假設(shè)使用標(biāo)準(zhǔn)的非鎖讀）。但是這有很高的代價(jià) – InnoDB需要去維護(hù)事務(wù)記錄，從一開始就要記錄，它的代價(jià)是非常昂貴的。更為嚴(yán)重的情況是，程序頻繁地更新和hot rows – 你真的就不想InnoDB去處理rows了，它有成百上千個(gè)版本。

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

　　下面是例子：完全在內(nèi)存中的數(shù)據(jù)集中運(yùn)行 sysbench，并啟動(dòng) transaction 、運(yùn)行全表、掃描、查詢幾次，同時(shí)保持 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

正如你可以看到的，寫（write ）操作的吞吐量大幅下降，并且持續(xù)走低，這時(shí)transaction 是開著的，不僅是在查詢（query）操作運(yùn)行的時(shí)候。在可復(fù)讀的隔離模式下，當(dāng)你已經(jīng)選擇了之外的transaction ，緊接著就是一個(gè)long transaction ，這也許是我能找到的最糟糕情況了。當(dāng)然了你也會(huì)在其他情況下看到回歸算法（regression ）。

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

　　READ UNCOMMITTED – 我覺得這是最難理解的隔離模式（悲催的只有2條文檔），只描述了它的邏輯觀點(diǎn)。如果你使用了這種隔離模式，你會(huì)看到數(shù)據(jù)控中所有發(fā)生的變化，即使是那些還沒被提交的transactions 。這種隔離模式一種好的用例是：你能“watch”到大規(guī)模的有臟讀（dirty reads）的UPDATE 語句，顯示了哪行被改變了，哪些沒有改變。

　　如果transaction 事務(wù)在運(yùn)行的時(shí)候出錯(cuò)了，那么這個(gè)聲明會(huì)顯示還沒被提交的和可能沒被提交的變化，所以使用這個(gè)模式要小心為妙。有一些用例雖然不需要我們100%準(zhǔn)確的數(shù)據(jù)，在這種情況下，這種模式就變得非常方便。

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

　　這些結(jié)果顯示這個(gè)備份的方法恢復(fù)的時(shí)間太長而不能用于大型數(shù)據(jù)集合，同樣這個(gè)方法受到性能影響，也不能用于頻繁寫入（write ）的環(huán)境中。

　　READ COMMITTED 模式和REPEATABLE READ模式很相似，本質(zhì)區(qū)別在于哪個(gè)版本都不在transaction中從頭開始讀取，取而代之的從當(dāng)前語句開始讀取。因此使用這種模式允許InnoDB少維護(hù)很多版本，特別是你沒有很長的statements要允運(yùn)行。如果你有很長的select要運(yùn)行，如報(bào)表查詢對(duì)性能的影響仍然很嚴(yán)重。

　　通常我認(rèn)為好的做法是把READ COMITTED隔離模式做為默認(rèn)，對(duì)于應(yīng)用程序或者transactions 有必要就改成REPEATABLE READ。

　　那么，從性能角度來看，如何體現(xiàn)READ UNCOMMITTED？理論上，InnoDB 可以清除行版本，在READ UNCOMMITTED模式下即便是該語句已經(jīng)開始執(zhí)行之后，也可以創(chuàng)建。在實(shí)踐中，由于一個(gè)bug或者一些復(fù)雜實(shí)現(xiàn)的細(xì)節(jié)做不到，語句開始仍然是行版本。所以，如果你在READ UNCOMMITTED聲明中運(yùn)行很長的SELECT，你會(huì)得到大量的行版本創(chuàng)建信息，就像你用了READ COMMITTED。No win here。

　　從SELECT方面還有一個(gè)重要的win - READ UNCOMMITTED隔離模式意味著InnoDB 不需要去檢查舊的行版本 - 最后一行總是對(duì)的，這會(huì)使得性能有明顯的改善，尤其是當(dāng)undo空間已經(jīng)在磁盤上溢出，查找舊的行版本會(huì)造成大量的IO讀寫。

　　也許上面這個(gè)select avg(k) from sbtest1;是我能找到的最好的查詢例子了，能與之類似的更新工作量。假使READ UNCOMMITTED隔離模式在一分鐘左右完成，我認(rèn)為在READ COMMITTED隔離模式下沒有完成過，因?yàn)樾滤饕龡l目插入的速度要比掃描速度快。

　　最后思考：正確的使用InnoDB 隔離模式，能夠讓您的應(yīng)用程序得到最佳性能。你得到的好處可能不同，在某些情況下，也可能沒什么區(qū)別。關(guān)系到InnoDB 的歷史版本，似乎好有好多工作要做，我希望在未來的MySQL中能解決。