mysql實戰45講 讀書筆記 3 事務隔離:爲什麼你改了我還看不見

一 序

本文屬於:極客時間mysql實戰45講 讀書筆記系列。

簡單來說,事務就是要保證一組數據庫操作,要麼全部成功,要麼全部失敗。以下InnoDB爲例介紹MySQL對於事務的支持。

二隔離性與隔離級別

提到事務,你肯定會想到ACID(Atomicity、Consistency、Isolation、Durability,即原子性、一致性、隔離性、持久性),今天我們就來說說其中I,也就是“隔離性”。

當數據庫上有多個事務同時執行的時候,就可能出現髒讀(dirty read)、不可重複讀(non-repeatable read)、幻讀(phantom read)的問題,爲了解決這些問題,就有了“隔離級別”的概念。

在談隔離級別之前,你首先要知道,你隔離級別越高,效率就會越低。因此很多時候,我們都要在二者之間尋找一個平衡點。SQL標準的事務隔離級別包括:讀未提交(read uncommitted)、讀提交(read committed)、可重複讀(repeatable read)和串行化(serializable )。

  • 讀未提交是指,一個事務還沒提交時,它做的變更就能被別的事務看到。
  • 讀提交是指,一個事務提交之後,它做的變更纔會被其他事務看到。
  • 可重複讀是指,一個事務執行過程中看到的數據,總是跟這個事務在啓動時看到的數據是一致的。當然在可重複讀隔離級別下,未提交變更對其他事務也是不可見的。
  • 串行化,顧名思義是對於同一行記錄,“寫”會加“寫鎖”,“讀”會加“讀鎖”。當出現讀寫鎖衝突的時候,後訪問的事務必須等前一個事務執行完成,才能繼續執行。

  爲了更好理解,假設數據表T中只有一列,其中一行的值爲1,下面是按照時間順序執行兩個事務的行爲。

mysql> create table T(c int) engine=InnoDB;
insert into T(c) values(1);

  

我們來看看在不同的隔離級別下,事務A會有哪些不同的返回結果,也就是圖裏面V1、V2、V3的返回值分別是什麼。

  • 若隔離級別是“讀未提交”, 則V1的值就是2。這時候事務B雖然還沒有提交,但是結果已經被A看到了。因此,V2、V3也都是2。
  • 若隔離級別是“讀提交”,則V1是1,V2的值是2。事務B的更新在提交後才能被A看到。所以, V3的值也是2。
  • 若隔離級別是“可重複讀”,則V1、V2是1,V3是2。之所以V2還是1,遵循的就是這個要求:事務在執行期間看到的數據前後必須是一致的。
  • 若隔離級別是“串行化”,則在事務B執行“將1改成2”的時候,會被鎖住。直到事務A提交後,事務B纔可以繼續執行。所以從A的角度看, V1、V2值是1,V3的值是2。

在實現上,數據庫裏面會創建一個視圖,訪問的時候以視圖的邏輯結果爲準。在“可重複讀”隔離級別下,這個視圖是在事務啓動時創建的,整個事務存在期間都用這個視圖。在“讀提交”隔離級別下,這個視圖是在每個SQL語句開始執行的時候創建的。這裏需要注意的是,“讀未提交”隔離級別下直接返回記錄上的最新值,沒有視圖概念;而“串行化”隔離級別下直接用加鎖的方式來避免並行訪問。

  MySQL 哪個隔離級別都有它自己的使用場景,你要根據自己的業務情況來定。RR 級別下select ..for update有死鎖的問題,RC就沒有。之前58到家就是RC級別.配置的方式是,將啓動參數transaction-isolation的值設置成READ-COMMITTED。你可以用show variables來查看當前的值。

mysql> show variables like 'transaction_isolation';

三 事務隔離的實現

理解了事務的隔離級別,我們再來看看事務隔離具體是怎麼實現的。這裏我們展開說明“可重複讀”。

在MySQL中,實際上每條記錄在更新的時候都會同時記錄一條回滾操作。記錄上的最新值,通過回滾操作,都可以得到前一個狀態的值。

假設一個值從1被按順序改成了2、3、4,在回滾日誌裏面就會有類似下面的記錄。

  

當前值是4,但是在查詢這條記錄的時候,不同時刻啓動的事務會有不同的read-view。如圖中看到的,在視圖A、B、C裏面,這一個記錄的值分別是1、2、4,同一條記錄在系統中可以存在多個版本,就是數據庫的多版本併發控制(MVCC)。對於read-view A,要得到1,就必須將當前值依次執行圖中所有的回滾操作得到。(注意:看這個圖要理解下,是從1改爲2,所以對應的回滾段要記爲將2改爲1,這樣才能起到回滾的作用。)

   什麼時候刪除呢回滾日誌呢?系統會判斷,當沒有事務再需要用到這些回滾日誌時(就是當系統裏沒有比這個回滾日誌更早的read-view的時候。),回滾日誌會被刪除。 

  基於上面的說明,我們來討論一下爲什麼建議你儘量不要使用長事務。

  1.  長事務意味着系統裏面會存在很老的事務視圖。由於這些事務隨時可能訪問數據庫裏面的任何數據,所以這個事務提交之前,數據庫裏面它可能用到的回滾記錄都必須保留,這就會導致大量佔用存儲空間。
  2. 除了對回滾段的影響,長事務還佔用鎖資源,也可能拖垮整個庫。

事務的啓動方式

MySQL的事務啓動方式有以下幾種:

  1. 顯式啓動事務語句, begin 或 start transaction。配套的提交語句是commit,回滾語句是rollback。

  2. set autocommit=0,這個命令會將這個線程的自動提交關掉。意味着如果你只執行一個select語句,這個事務就啓動了,而且並不會自動提交。這個事務持續存在直到你主動執行commit 或 rollback 語句,或者斷開連接。

建議你總是使用set autocommit=1, 通過顯式語句的方式來啓動事務。

你可以在information_schema庫的innodb_trx這個表中查詢長事務,比如下面這個語句,用於查找持續時間超過60s的事務。

select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章