spring事務的隔離級別。如何避免髒讀或者幻讀
事務隔離級別為四個等級，預設是資料庫的隔離級別，需要去資料庫查詢一下隔離級別：
1.檢視當前會話隔離級別 select @@tx_isolation;
2.檢視系統當前隔離級別 select @@global.tx_isolation;
隔離級別：Isolation Level，也是RDBMS的一個關鍵特性。相信對資料庫有所瞭解的朋友，對於4種隔離級別：Read Uncommited，Read Committed，Repeatable Read，Serializable，都有了深入的認識。本文不打算討論資料庫理論中，是如何定義這4種隔離級別的含義的，而是跟大家介紹一下MySQL/InnoDB是如何定義這4種隔離級別的。
2、事務併發會產生什麼問題
1）第一類丟失更新：在沒有事務隔離的情況下，兩個事務都同時更新一行資料，但是第二個事務卻中途失敗退出， 導致對資料的兩個修改都失效了。
例如：
張三的工資為5000，事務A中獲取工資為5000，事務B獲取工資為5000，匯入100，並提交資料庫，工資變為5100，
隨後
事務A發生異常，回滾了，恢復張三的工資為5000，這樣就導致事務B的更新丟失了。
2）髒讀：髒讀就是指當一個事務正在訪問資料，並且對資料進行了修改，而這種修改還沒有提交到資料庫中，這時，另外一個事務也訪問這個資料，然後使用了這個資料。
例如：
張三的工資為5000,事務A中把他的工資改為8000,但事務A尚未提交。
與此同時，
事務B正在讀取張三的工資，讀取到張三的工資為8000。
隨後，
事務A發生異常，而回滾了事務。張三的工資又回滾為5000。
最後，
事務B讀取到的張三工資為8000的資料即為髒資料，事務B做了一次髒讀。
3）不可重複讀：是指在一個事務內，多次讀同一資料。在這個事務還沒有結束時，另外一個事務也訪問該同一資料。那麼，在第一個事務中的兩次讀資料之間，由於第二個事務的修改，那麼第一個事務兩次讀到的的資料可能是不一樣的。這樣就發生了在一個事務內兩次讀到的資料是不一樣的，因此稱為是不可重複讀。
例如：
在事務A中，讀取到張三的工資為5000，操作沒有完成，事務還沒提交。
與此同時，
事務B把張三的工資改為8000，並提交了事務。
隨後，
在事務A中，再次讀取張三的工資，此時工資變為8000。在一個事務中前後兩次讀取的結果並不致，導致了不可重複讀。
4）第二類丟失更新：不可重複讀的特例。
有兩個併發事務同時讀取同一行資料，然後其中一個對它進行修改提交，而另一個也進行了修改提交。這就會造成第一次寫操作失效。
例如：
在事務A中，讀取到張三的存款為5000，操作沒有完成，事務還沒提交。
與此同時，
事務B，儲存1000，把張三的存款改為6000，並提交了事務。
隨後，
在事務A中，儲存500，把張三的存款改為5500，並提交了事務，這樣事務A的更新覆蓋了事務B的更新。
5）幻讀：是指當事務不是獨立執行時發生的一種現象，例如第一個事務對一個表中的資料進行了修改，這種修改涉及到表中的全部資料行。同時，第二個事務也修改這個表中的資料，這種修改是向表中插入一行新資料。那麼，以後就會發生操作第一個事務的使用者發現表中還有沒有修改的資料行，就好象發生了幻覺一樣。
例如：
目前工資為5000的員工有10人，事務A讀取所有工資為5000的人數為10人。
此時，
事務B插入一條工資也為5000的記錄。
這是，事務A再次讀取工資為5000的員工，記錄為11人。此時產生了幻讀。
提醒：
不可重複讀的重點是修改，同樣的條件，你讀取過的資料，再次讀取出來發現值不一樣了
幻讀的重點在於新增或者刪除，同樣的條件，第 1 次和第 2 次讀出來的記錄數不一樣
1.MySQL/InnoDB定義的4種隔離級別
：
1.1 Read Uncommited
這是事務最低的隔離級別，它充許另外一個事務可以看到這個事務未提交的資料。
解決第一類丟失更新的問題，但是會出現髒讀、不可重複讀、第二類丟失更新的問題，幻讀 。
可以讀取未提交記錄。此隔離級別，不會使用，忽略。
1.2 Read Committed (RC)
快照讀忽略，本文不考慮。
保證一個事務修改的資料提交後才能被另外一個事務讀取，即另外一個事務不能讀取該事務未提交的資料。
解決第一類丟失更新和髒讀的問題，但會出現不可重複讀、第二類丟失更新的問題，幻讀問題
針對當前讀，RC隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，存在幻讀現象。
1.3 Repeatable Read (RR)
快照讀忽略，本文不考慮。
保證一個事務相同條件下前後兩次獲取的資料是一致的
解決第一類丟失更新，髒讀、不可重複讀、第二類丟失更新的問題，但會出幻讀。
針對當前讀，RR隔離級別保證對讀取到的記錄加鎖 (記錄鎖)，同時保證對讀取的範圍加鎖，新的滿足查詢條件的記錄不能夠插入 (間隙鎖)，不存在幻讀現象。如果對統一條記錄A在進行讀操作， B也可以進行讀操作和寫操作，如果A在進行寫操作，B也
1.4 Serializable
從MVCC併發控制退化為基於鎖的併發控制。不區別快照讀與當前讀，所有的讀操作均為當前讀，讀加讀鎖 (S鎖)，寫加寫鎖 (X鎖)。
Serializable隔離級別下，讀寫衝突，因此併發度急劇下降，在MySQL/InnoDB下不建議使用。
只需要在新增事務額註解上加上這樣的程式碼即可提升事務的隔離級別：
@Transactional(rollbackFor = OrderProcException.class, isolation = Isolation.SERIALIZABLE)**
4、InnoDB引擎的鎖機制
**
（之所以以InnoDB為主介紹鎖，是因為InnoDB支援事務，支援行鎖和表鎖用的比較多，Myisam不支援事務，只支援表鎖）
共享鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同資料集的排他鎖。
排他鎖（X)：允許獲得排他鎖的事務更新資料，阻止其他事務取得相同資料集的共享讀鎖和排他寫鎖。
意向共享鎖（IS）：事務打算給資料行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
意向排他鎖（IX）：事務打算給資料行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。
說明：
1）共享鎖和排他鎖都是行鎖，意向鎖都是表鎖，應用中我們只會使用到共享鎖和排他鎖，意向鎖是mysql內部使用的，不需要使用者干預。
2）對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及資料集加排他鎖（X)；對於普通SELECT語句，InnoDB不會加任何鎖，事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。
共享鎖（S）：SELECT * FROM table_name WHERE … LOCK IN SHARE MODE。
排他鎖（X)：SELECT * FROM table_name WHERE … FOR UPDATE。
3）InnoDB行鎖是通過給索引上的索引項加鎖來實現的，因此InnoDB這種行鎖實現特點意味著：只有通過索引條件檢索資料，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！。