淺析MySQL事務隔離級別對其性能的影響
MySQL對事務的隔離級別共分爲四個級別，分別是：
1. READ UNCOMMITTED 讀未提交
2. READ COMMITTED 讀提交
3. REPEATABLE 可重讀
4. SERIALIABLE 可串讀
MySQL默認工作在級別三下。我們知道事務隔離是爲了避免併發操作相互影響而導數據的不一致性。所以爲了保證數據的一致性，就引入了事務隔離的功能。以上四個級別的對數據的一致性保護是逐步提高的。級別4對事務的隔離效果最好，但是性能最差，一般不再生產環境中使用。
下面通過實例來檢驗不同級別下MySQL性能收到的影響。我的實驗環境是：Redhat5.8+MySQL5.5
首先我們這裏啓用兩個session：
1、驗證級別一的特性
我們在session A上進行的操作爲：
在session B上的操作同session A，這裏不再附上截圖。
接下來我們就通過一系列的實驗來觀察READ-UNCOMMITTED到底是什麼，它到底有什麼特性，對我們的操作到底有什麼影響。首先，我們可以看到表中的初始數據如下：
接下來我們在sessionA上更改其中的一條記錄，更改結果如下：
注意：我們在上面啓用了事務，但是我們在這裏並沒有進行commit操作。
接下來我們在sessionB中對剛纔改過的表進行select查詢，查詢結果如下：
我們可以清楚的看到，雖然我們並沒有對session A的結果進行commit，但是結果確實已經改變。因此在這種級別下，沒有提交的操作會對數據的一致性有影響。因此，如果我們此時在session A上對上述操作進行回滾，我們會發現此時session B上的結果又回到原來最初的結果，這樣就造成了數據的不一致性，這也稱爲數據的幻讀現象，看起來是很詭異的事情。因此在某些場景下，我們應該避免這種現象的產生。但是這種級別也不是沒有它的用武之地，比如當我們有大量數據需要寫入，而讀操作很少的時候，就適合用這種模式。
可以看到session A回滾後，session B中的數據又變成最初的樣子，這也稱爲幻讀：
2、驗證級別READ COMMITTED特性
首先把session A和session B的隔離級別都改爲READ-COMMITTED，並且全部都開啓事務，操作如下：
接下來我們查看tutors表的初始狀態信息：
然後我們依然是對數據進行更新操作，更新之後仍然沒有commit。我們可以看到在sessionA中，結果已經發生改變：
此時我們在session B中查看，發現結果依然維持不變：
但是，如果我們此時在session A中進行commit操作，我們就會發現，sessionB此時查詢就會發生改變，這樣也造成了數據的前後不一致性，也是數據的幻讀：
3、數據的可重讀
數據的可重讀，也叫作REPEATABLE-READ，這是MySQL默認採用的事務隔離級別，有其優勢，但是仍然沒有從根本上解決數據的一致性問題。首先，還是讓我們來測試一下，在這種級別下MySQL到底是如何工作的，又有哪些特性，我們又該怎樣去操作。
我們先把REPEATABLE-READ的環境設置好，具體的操作方法如下：
然後我們在查看其初始數據，其結果如下：
我們在session A中修改數據，並進行commit，修改後的結果如下：
然後我們在session B中進行查看發現結果仍然沒有任何改變：
這就是可重讀的特性，只要本次會話不提交，儘管對方修改，但是結果仍然不變，只有在session B中也進行commit操作，所作的修改纔會在sessionB中生效。
4、seriabliable
這個級別是事務隔離安全性最好的，但是也是性能最差的，因爲這個級別所有的操作都是串行進行的。一個操作沒有提交，另一個受到影響的操作會處於阻塞狀態。
爲了驗證這種效果，我們先把環境設置好，具體爲在session A和session B同時設置如下：
在session A 中對其任意字段進行修改，並且沒有進行commit操作。此時揮發現sessionB中的查詢操作會一直處於阻塞狀態：
這就設串行化隔離的效果，也是爲什麼串行化隔離併發能力差的原因。
實驗測試用的數據我已經上傳。