【搞定MySQL資料庫】第5篇：事務隔離
本文為本人學習極客時間《MySQL實戰45講》的學習筆記。
原文連結：https://time.geekbang.org/column/article/68963
本文目錄：
可以先閱讀這篇文章：【搞定MySQL資料庫】之事務的4種隔離級別詳解
1、隔離性與隔離級別
當提到事務，你肯定會想到 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);
在實現上，資料庫裡面會建立一個檢視，訪問的時候以試圖的邏輯結果為準。
在“可重複讀”隔離級別下，這個檢視是在事務啟動時建立的，整個事務存在期間都用這個檢視。
在“讀提交”隔離級別下，這個檢視是在每個SQL語句開始執行的時候建立的；
在“讀未提交”隔離界別下，直接返回記錄上的最新值，沒有檢視的概念；
在“序列化”隔離級別下，使用加鎖的方式來避免並行訪問。
我們可以看到在不同的隔離級別下，資料庫行為是有所不同的。Oracle 資料庫的預設隔離級別其實就是“讀提交”，因此對於一些從 Oracle 遷移到 MySQL 的應用，為保證資料庫隔離級別的一致，你一定要記得將 MySQL 的隔離級別設定為讀提交”。
配置的方式是：將啟動引數 transaction-isolation 的值設定成 READ-COMMITTED。你可以用 show variables 來檢視當前的值。
mysql> show variables like 'transaction_isolation';
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+
總結來說，存在即合理，哪個隔離級別都有它自己的使用場景，你要根據自己的業務情況來定。
2、事務隔離的實現
理解了事務的隔離級別，我們再來看看事務隔離級具體是怎麼實現的。這裡我們展開說明“可重複讀”。
在 MySQL 中，實際上每條記錄在更新的時候都會同時記錄一條回滾操作。記錄上的最新值，通過回滾操作，都可以得到前前一個狀態的值。
假設一個值從 1 被按順序改成 2、3、4，在回滾日誌裡面就會有類似下面的記錄。
當前值是4，但是在查詢這條記錄的時候，不同時刻啟動的事務會有不同的 read-view。如上圖所示看到的，在檢視A、B、C裡面，這一個記錄的值分別是1、2、4，同一條記錄在系統中可以存在多個版本，就是資料庫的多版本併發控制（MVCC）。對於 read-view A，要得到1，就必須將當前值依次執行圖中所有的回滾操作得到。
同時你會發現，即使現在有另外一個事務正在將 4 改成 5 ，這個事務跟 read-view A、B、C對應的事務是不會衝突的。
你一定會問，回滾日誌總不能一直保留吧，什麼時候刪除呢？答案是，在不需要的時候才刪除。也就是說，系統會判斷，當沒有事務再需要用到這些回滾日誌時，回滾日誌會被刪除。
什麼時候才不需要了呢？就是當系統裡沒有比這個回滾日誌更早的 read-view 的時候。
基於上面的說明，我們來討論一下為什麼建議你儘量不要使用長事務。
長事務意味著系統裡面會存在很老的事務檢視。由於這些事務隨時可能訪問資料庫裡面的任何資料，所以這個事務提交之前，資料庫裡面它可能用到的回滾記錄都必須保留，這就會導致大量佔用儲存空間。
除了對回滾段的影響，長事務還佔用鎖資源。
3、事務的啟動方式
如前面所述，長事務有這些潛在風險，我當然是建議你儘量避免。其實很多時候業務開發同學並不是有意使用長事務，通常是由於誤用所致。MySQL 的事務啟動方式有以下幾種：
1、顯示啟動事務語句，begin 或 start transaction。配套的提交語句是 commit，回滾語句是 rollback；
2、set autocommit=0，這個命令會將這個執行緒的自動提交關掉。意味著如果你只執行一個 select 語句，這個事務就啟動了，而且不會自動提交。這個事務持續存在直到你主動執行 commit 或者 rollback 語句，或者斷來連線。
有些客戶端連線框架會預設連線成功後先執行一個 set autocommit=0 的命令。這就導致接下來的查詢都在事務中，如果是長連線，就導致了意外的長事務。
因此，建議總是使用set autocommit=1, 通過顯式語句的方式來啟。
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60