SQL中的Isolation
實驗SQL語句案例：
-- SELECT @@session.tx_isolation; 查看當前的isolation
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
-- SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET autocommit=0;
START transaction;
-- 修改不同的值，配合 select * from test_acid where id=1; 對讀寫情況進行觀察
update test_acid set score=100 where id=1;
COMMIT;
-- 其他事務的測試，最後執行SET autocommit=1; 恢復缺省設置
上面是我畫的一個便於理解四個isolation級別的圖，沒有研究過數據庫具體的實現，所以只是一個理解示意圖。
| Isolation | select 讀 | update 寫（一般處理） | update 寫（存在SERIALIZABLE事務設置的行鎖，即讀過或者寫過） |
|---|---|---|---|
| READ UNCOMMITTED | 獲得提交數據（如存在）。但這個風險，可能會rollback，但這是最新的數據。 | 如果存在提交數據，要排隊等待，有阻塞。 | 必須等該SERIALIZABLE事務結束，然後按一般處理。 |
| READ COMMITTED | 獲取磁盤數據，除非是自己的提交。 | 如果存在提交數據，要排隊等待，有阻塞。 | 必須等該SERIALIZABLE事務結束，然後按一般處理。 |
| REPEATABLE READ | 第一次讀，則獲取磁盤數據；後續的讀，則返回第一次讀的數據，除非被自己提交。
無論在事務的過程中，數據是否發生變化，保持本事務內視圖一致。 |
如果存在提交數據，要排隊等待，有阻塞。 | 必須等該SERIALIZABLE事務結束，然後按一般處理。 |
| SERIALIZABLE | 如果存在提交數據，等待其寫入磁盤，有阻塞。 | 只要在事務期間，數據存在修改，無論是在提交數據還是磁盤，均報錯。 | 報錯 |
我建議能夠要前面給的測試SQL來進行檢驗，這樣可以加強理解。最要直接用 mysql client 連接數據庫，而不是使用什麼 workbench 之類的工具。每個mysql client就是一個session，所設置的isolation在本session內生效。
基於Hibernate的Spring Data
使用JAVA代碼，其實和SQL沒有什麼區別，最終都是要將SQL語句傳遞給mysql server來執行，但是通過上一學習，我們需要注意，傳遞的sql並不一定按照代碼的時序：
- Spring Data的寫SQL是在最後commit前發出，這最大程度地縮短了寫操作和commit之間的時間。
- 對相同的ID的讀，JPA只從數據庫中讀取一次。
- 從數據庫中獲取entity，修改entity的數據，即使最後沒有執行save，在commit之前，發送update。
| isolation | read | 併發 非SERIALIZABLE 的寫 | 併發 SERIALIZABLE 事務（無論讀寫） |
|---|---|---|---|
| Isolation.READ_UNCOMMITTED | 讀取提交內容（如果有） | 等待提交內容commit，阻塞 | |
| Isolation.READ_COMMITTED | 讀取磁盤存儲內容 | 等待提交內容commit，阻塞 | |
| Isolation.REPEATABLE_READ | JPA中只讀一次，很難重新現象。 | 等待提交內容commit，阻塞 | |
| Isolation.SERIALIZABLE | 如果有其他事務的寫鎖，等待其他事務完成，阻塞 | 對於Spring Data，update操作先會觸發讀，讀會先等等其他完成。一旦serializable讀，其他的寫就必須等其commit完成。這個測試環境不存在。
如果採用JPA，直接進行寫操作，或報告異常。和SQL語句測試一樣，只要在事務期間，數據存在修改，無論是在提交數據還是磁盤，均報錯。 |
|
對於SERIALIZABLE，只要其對數據進行操作，即使是隻讀，其他的事物都必須等待其完成。也就是對於數據享有唯一處理的權限。