【資料庫】Levels of Isolation
相關資料來源於網路，侵刪歉。 如果文章中存在錯誤，請下方評論告知我，謝謝！
何時程式設計師需要在應用層自己控制併發事務？ DBMS在處理系統的併發事務時，其事務排程器通過應用兩段鎖協議(2PL)來保證產生可序列化的排程。當應用中存在著大量的併發事務，鎖的衝突會越來越多，這將導致越來越多的事務處於等待狀態，系統中發生死鎖的次數亦會隨之增加。因此，對於實際應用，2PL有時顯得過於嚴格。為了提高系統的效能，SQL-99語法中允許在啟動事務的SQL語句之前，應用程式設計師(根據應用的需要)自己設定隔離級別，以保證事務的序列性。
SQL-99提供的四種隔離級別為： 1) Read Uncommitted 2) Read Committed 3) Repeatable Read 4) Serializable
SQL-99 提供的設定隔離級別的語句 SET TRANSACTION ( READ ONLY | READ WRITE) ISOLATION LEVEL ( READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE ); 實際上該語句定義了事務的兩個性質：1)事務的型別 (Read only/Read Write)；2)設定事務的隔離級別。
Read Uncommitted 一個事務讀的時候允許其他事務操作，寫的時候其他事物只能讀不能寫。 允許一個事務讀取到未提交的資料，即 Read Uncommitted 解決了丟失修改問題，但不能解決讀髒資料和不可重複讀問題。
Read Committed 一個事務讀的時候允許其他事務操作，修改的時候不允許任何其它事務讀寫。 事務只能讀取到提交了的資料，即Read Committed 解決了丟失修改、讀髒資料問題，但不能解決不可重複讀問題。
Repeatable Read 一個事務讀取的時候其他事務不可修改（允許讀），寫事務的時候禁止其他任何事務。 解決了丟失修改、讀髒資料、不可重複讀問題，但可能出現讀幻影現象。
Serializable 事務可序列化執行。 使用表級鎖，解決讀幻影現象。
|
不一致性 隔離級別 |
丟失修改(lost update) |
髒讀資料(Dirty Read) |
不可重複讀(Non Repeatable Read) |
幻讀(Phantom Read) |
|
讀未提交（Read uncommitted） |
不可能 |
可能 |
可能 |
可能 |
|
讀已提交（Read committed） |
不可能 |
不可能 |
可能 |
可能 |
|
可重複讀（Repeatable read） |
不可能 |
不可能 |
不可能 |
可能 |
|
可序列化（Serializable ） |
不可能 |
不可能 |
不可能 |
不可能 |