三大併發異常現象
| 現象 | 說明 | 例子 |
|---|
| 髒讀 | 讀到未提交的修改，回滾後數據錯誤 | 事務 A 修改未提交，事務 B 讀取，A 回滾 → B 數據無效 |
| 不可重複讀 | 同一事務兩次讀同一行，值不同 | 事務 A 讀 total=100，事務 B 改為 200 提交，A 再讀變 200 |
| 幻讀 | 同一查詢條件兩次結果集行數不同 | 事務 A 查 name='ppgogo*' 得 6 行，事務 B 插入新行滿足條件，A 再查得 7 行 |
SQL 標準四大隔離級別
| 級別 | 髒讀 | 不可重複讀 | 幻讀 | 實現機制 | 並發性能 |
|---|
| Serializable | ✓ | ✓ | ✓ | 嚴格串行化（表鎖/謂詞鎖） | 最低 |
| Repeatable Read | ✓ | ✓ | ✗ | 共享讀鎖 + 排他寫鎖 | 低 |
| Read Committed | ✓ | ✗ | ✗ | 瞬時共享讀鎖 + 排他寫鎖 | 中（多數 DB 預設） |
| Read Uncommitted | ✗ | ✗ | ✗ | 排他寫鎖 | 最高 |
選型建議
- 預設用 Read Committed：避免髒讀，兼顧並發，Oracle/PostgreSQL/SQL Server/MySQL InnoDB 預設皆為此級別。
- 業務需強一致性（財務對賬、庫存扣減關鍵點）：升級 Repeatable Read 或 Serializable，或在應用層加悲觀鎖（
SELECT ... FOR UPDATE）/樂觀鎖（版本號/時間戳）。
- 唯讀報表/數據分析：可降級 Read Uncommitted 獲取最大吞吐，容忍髒讀。
補充：更新丟失
- 第一類：事務 A 提交，事務 B 回滾覆蓋 A 的修改 → 可由資料庫鎖機制避免。
- 第二類：兩事務基於同一查詢結果並發更新，後提交者覆蓋前者 → 本質是不可重複讀特例，需應用層樂觀鎖解決。
隔離級別越高，一致性越強、並發越低；架構師須在業務語義與效能間精準平衡。
