MySQL 事務隔離級別

1、事務描述

一、事務的四個特性 ACID

　　1. A：原子性 = 一個事務或者都成功、或者都失敗；

　　2. C：一致性 = 在整個事務的生命週期裏面，查詢到的數據是一致的；

　　　　MVCC多版本併發控制：利用undo保存某一時刻數據快照，經過版本號來減小鎖的爭用，保證各個事務互不影響。

　　3. I：  隔離性 = 隔離級別；

　　4. D：持久性 = 只要事務commit，這個事務不會由於系統的崩潰而丟失；

　　持久性和原子性對於全部的支持事務的數據庫都是同樣的，都知足。

二、常見事務格式

start transaction;

　　DML ( insert; delete; update; )

commit;

三、MySQL 默認每一條 DML 是一個事務

　　經過參數 'autocommit' 進行控制是否默認提交事務；

mysql> show variables like 'autocommit'; +---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.01 sec)

　　 SQL 自動提交開啓，有必定的危險性(沒有 rollback )。

　　牆裂推薦：關閉 SQL 的自動提交；

　　血淚教訓：曾經自信過了頭的一次 sitesup （其實也是有反覆確認），同時疏忽了備份，命令行下一個回車敲下去，發現問題大發了……因此，備份 + 顯式 Commit 很重要。

四、大事務+長事務

　　數據庫的大事務和長事務會帶來undo的持續增長、undo暴增，空間不可複用；

　　事務信息表：information_schema.INNODB_TRX，用來查看長事務、大事務。

五、空閒事務+鎖

start transaction;

　　update;

　　……    // 空閒等待，時間可能不可控

　　……    // 空閒等待

　　update;

commit;

　　1. 事務和事務鎖有必定的關係：事務不提交、行鎖就不會釋放、事務鎖就不會消失

　　2. 死鎖：是指兩個或兩個以上的事務在執行過程當中，因爭奪鎖資源而形成的一種相互等待的現象。死鎖出現的機率是很是低的，由於innodb內置有死鎖檢查機制，當出現死鎖時會自動回滾佔用undo資源少的事務。

 

2、事務隔離級別

0、隔離性

　　1. MySQL 有多個隔離級別，能夠調整，隔離性越弱併發性越好；

　　2. 每一個數據庫都有本身默認的隔離級別

mysql> show variables like '%iso%'; +---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| tx_isolation  | REPEATABLE-READ |
+---------------+-----------------+
1 row in set (0.01 sec)

 　　會話級別設置：set @@session.tx_isolation=……

一、READ-UNCOMMITED

　　未提交讀，隔離性最弱，但併發性最好；

　　事務中的修改，即便沒有提交，對其餘事務也都是可見的，也就是說事務能夠讀取未提交的數據，讀到髒數據(髒讀，dirty read)；

二、READ-COMMITED

　　大部分數據庫系統的默認隔離級別都是READ-COMMITED，但MySQL不是；

　　1. 提交讀，一個事務從開始直到提交以前，所作的任何修改對其餘事務都是不可見的；

　　2. 不可重複讀，在同一個事務中，同一個SQL執行屢次(該記錄修改事務提交前、提交後)，獲得的結果可能不一樣：幻讀；

三、REPEATABLE-READ

　　可重複讀，MySQL默認隔離級別；

　　在同一個事務中，同一個SQL執行屢次，獲得的結果是相同的；

　　1. 對於普通 select 來講，經過 MVCC 來實現，解決髒讀問題、幻讀問題；

　　2. 對於 dml、select for update，經過範圍鎖實現，解決幻讀問題；

四、SERIALIZABLE

　　(serializable 連載、串行化) 隔離性最高，沒有併發；

　　對於同一個數據來講，在同一個時間段內，只能有一個會話能夠訪問，包括select和dml，經過執行事務串行執行，避免幻讀問題；

　　也就是說，對於同一行記錄，「寫」會加「寫鎖」，「讀」會加「讀鎖」。當出現讀寫鎖衝突的時候，後訪問的事務必須等前一個事務執行完成，才能繼續執行。

　　注意：業務有串行化的需求，可是咱們不會設置數據庫事務爲串行化隔離級別，而是在應用端設置解決(例：U盾)。