這是一個真實的故事
| Session A | Session B |
|---|---|
| start transaction; | |
| start transaction; | |
| select name from user where id = 1; //liunim | |
| update user set name =’liunim_modified’ where id = 1; | |
| commit; | |
| select name from user where id = 1; //liunim | |
| commit; |
這就是數據庫事務隔離級別跟我的第一次過招場景。
原因： 數據庫的事務隔離級別被設置爲REPEATABLE-READ，導致Session A對數據的修改不能被Session B中已經開啓的事務讀取到。
數據庫系統的事務
- 數據庫系統的事務應遵循ACID原則:
- 原子性(Atomicity)
對數據庫操作的原子單位就是事務，同一個事務內的數據庫操作(也就是sql語句)要麼全部成功，要麼全部失敗。
- 一致性(Consistency)
在事務提交以前數據庫中的所有數據滿足所有的約束，在事務提交以後數據庫中的所有數據也要滿足所有的約束。
- 隔離性(Isolation)
每個事務的執行是獨立的，事務的執行過程中彼此不受影響。
- 持久性(Durabilily)
一旦事務提交，對數據庫進行的操作就要永久的保留下來。
原子性
一致性
隔離性
Mysql事務隔離級別
四種隔離級別
- READ-UNCOMMITED
當一個session的事務隔離級別被設置爲讀未提交時，該session創建的事務中的查詢語句可以讀取到其他session開啓的事務裏面對數據進行的更改，即使事務未提交。
測試時候注意 連接被重置以後 之前設置的 事務隔離級別 以及關閉掉的自動提交均會恢復至默認值。
(此隔離級別會出現 讀髒、不可重複讀、幻讀)
- READ-COMMITED
事務隔離級別爲讀已提交的事務中，可以讀取到其他事務提交的對數據的修改，也就是說在同一個事務中多次讀取同一條數據，會得到不同的值(在此期間有其他事務對該數據進行修改，並且提交)。
(此隔離級別會出現 不可重複讀、幻讀)
- REPEATABLE-READ
mysql InnoDB引擎默認的事務隔離級別，可重複讀是指的在同一個未提交的事務中每次讀取到的同一條數據的值是不變的。不變是相對於事務開啓的那一刻的值不變。也就是說事務的隔離級別爲可重複讀的情況下，事務中的任何語句感知不到其他事務對同一條數據進行的修改，即使其他事務已提交。
帶有 for update的查詢例外 他可以讀取到已提交的數據。可重複讀只針對查詢。
(此隔離級別會出現 幻讀)
- SERIALIZABLE
查看&設置隔離級別
查看系統級隔離級別、會話級的事務隔離級別：
select @@global.tx_isolation,@@tx_isolation;設置隔離級別：
set session tx_isolation='read-uncommitted'; //session級別
set global tx_isolation='read-uncommitted'; //系統全局
Oracle事務隔離級別
暫時還未接觸,敬請期待……
SqlServer事務隔離級別
暫時還未接觸,敬請期待……