MySQL筆記（7）-- 事務和實現
一、背景
前面有說到InnoDB是事務型引擎，那什麼是事務？事務的特性是什麼？它所對應的隔離級別是哪些？是怎麼實現的？下面來詳細討論下。
二、事務的理解
事務就是一組原子性的SQL查詢，或者說一個獨立的工作單元。如果資料庫引擎能夠成功地對資料庫應用該組查詢的全部語句，那麼就執行該組語句。如果其中有任何一條語句因為崩潰或其他原因無法執行，那麼所有的語句都不會執行。也就是說，事務內的語句，要麼全部執行成功，要麼全部執行失敗。
可以用銀行轉賬的例子來解釋事務的必要性。如果一個銀行的資料庫有兩張表，支票表和儲蓄表，現在使用者張三從他的支票賬戶轉移200元到他的儲蓄賬號，那麼需要發生至少三個步驟：
- 檢查支票賬號的餘額高於200元；
- 從支票賬號餘額中減去200元；
- 在儲蓄賬號餘額中增加200元。
上述三個步驟的操作必須打包在一個事務中，任何一個事務的失敗，則必須回滾所有的步驟，即支票賬號和儲蓄賬號都回到這個轉賬操作的最初狀態。
可以用start transaction語句開始一個事務，然後用commit提交事務將修改的資料持久保留或使用rollback撤銷所有的修改。事務SQL的樣本如下：
start transaction; select balance from checking where customer_id=1; update checking set balance=balance-200.00 where customer_id=1; update savings set balance=balance+200.00 where customer_id=1; commit;
單純的事務不是這個故事的全部。試想一下，如果執行到第四條語句時伺服器崩潰了，會發生什麼？可能會損失200元。再假如，在執行到第三條語句和第四條語句之間時，另外一個程序要刪除支票賬號的所有餘額，那麼結果可能是銀行在不知道這個邏輯的情況下白白給了張三200元。
因此引出了下面的概念，事務的特性，即除非系統通過嚴格的ACID測試，否則空談事務的概念是不夠的。一個良好的事務處理系統，必須具備這些標準特性。
三、事務的特性
1.原子性（atomicity）
一個事務必須視為一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性。
2.一致性（consistency）
資料庫總是從一個一致性的狀態轉換到另一個一致性的狀態。在前面的例子中，一致性確保了，即使在執行第三、四條語句之間時系統崩潰，支票賬號中也不會損失200元，因為事務最終沒有提交，所以事務中所做的修改也不會儲存到資料庫中。一致性可以理解是例子中----開始的支票賬號總數加上儲蓄賬號總數之和，等於轉賬結束後支票賬號總數加上儲蓄賬號總數之和。
3.隔離性（isolation）
通常來說，一個事務所做的修改在最終提交之前，對其他事務是不可見的。在前面的例子中，當執行第三條語句、第四條語句還未開始時，此時有另外一個賬號匯款過來，則其看到的支票賬號餘額並沒有被減去200元。這當我們後面討論隔離級別時，會發現為什麼我們要說“通常來說”是不可見的。
4.永續性（durability）
一旦事務提交，則其所做的修改就會永久儲存到資料庫中。比如寫redo log日誌。
一個實現了ACID的資料庫，比沒有實現ACID的資料庫，通常會需要更強的CPU處理能力、更大的記憶體和更多的磁碟空間。這也是MySQL的儲存引擎架構可以發揮優勢的地方，使用者可以根據業務來判斷是否需要事務處理，來選擇合適的儲存引擎。對於一些不需要事務的查詢類應用，選擇一個非事務型的儲存引擎，可以獲得更高的效能。即使儲存引擎不支援事務，也可以通過LOCK TABLES加鎖和UNLOCK TABLES解鎖語句來提供一定程度的保護。
四、隔離級別
1.READ UNCOMMITTED（未提交讀）
在READ UNCOMMITTED級別，事務中的修改，即使沒有提交，對其他事務也都是可見的。事務讀取未提交的資料，稱為髒讀（Dirty Read）。
2.READ COMMITTED（提交讀）
大多數資料庫系統的預設隔離級別都是READ COMMITTED（但MySQL不是）。一個事務開始時，只能“看見”已經提交的事務所做的修改。換句話說，一個事務從開始直到提交之前，所做的任何修改對其他事務都是不可見的。這個級別有時也叫不可重複讀（nonrepeatable read)，因為兩次執行同樣的查詢，可能會得到不一樣的結果。【針對update更新操作】
3.REPEATABLE READ（可重複讀）
REPEATABLE READ解決了髒讀的問題，保證了在同一個事務中多次讀取同樣記錄的結果是一致的，但還是存在幻讀的問題，即當某個事務在讀取某個範圍內的記錄時，另外一個事務又在該範圍內插入了新的記錄，當之前的事務再次讀取該範圍的記錄時，會產生幻行。InnoDB儲存引擎通過多版本併發控制（MVCC,Multiversion Concurrency Control）解決了幻讀的問題。該級別是MySQL的預設事務隔離級別。【針對insert插入操作】
4.SERIALIZABLE（可序列化）
通過強制事務序列執行，避免了幻讀的問題。簡單來說，SERIALIZABLE會在讀取的每一行資料上都加鎖，所以可能導致大量的超時和鎖爭用的問題。“寫”會加“寫鎖”，“讀”會加“讀鎖”，當出現讀寫鎖衝突時，後訪問的事務必須等前一個事務執行完成，才能繼續執行。
其中“提交讀”和“可重複讀”可能比較難理解，所以下面用一個例子說明這幾種隔離級別。假設資料表T只有一列，其中一行的值為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語句開始執行的時候建立的；
- 在”可重複讀“隔離級別下，檢視是在事務啟動時建立的，整個事務存在期間都用這個檢視；事務啟動時的檢視可以認為是靜態的，不受其他事務更新的影響；
- 在“序列化”隔離級別下直接用加鎖的方式來避免並行訪問。
在不同的隔離級別下，資料庫行為是有所不同的。Oracle資料庫的預設隔離級別是“提交讀”，因此如果你想一些資料從Oracle遷移到MySQL，為保證資料庫隔離級別的一致，你要將MySQL的隔離級別設定為“提交讀”。配置的方式是，將啟動引數transaction-isolation的值設定為READ-COMMITTED。你可以用show variables來檢視當前的值。
mysql> show variables like 'transaction_isolation'; +-----------------------+----------------+ | Variable_name | Value | +-----------------------+----------------+ | transaction_isolation | READ-COMMITTED | +-----------------------+----------------+
五、事務隔離的實現
理解了事務的隔離級別，那麼事務隔離是怎麼實現的呢？這裡以“可重複讀”來展開說明。
在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的時候。
基於上面的說明，我們來討論下為什麼建議你儘量不要使用長事務。
長事務意味著系統裡面會存在很老的事務檢視，由於這些事務隨時可能訪問資料庫裡面的任何資料，所以這個事務提交之前，資料庫裡面它可能用到的回滾記錄都必須保留，這就導致大量佔用儲存空間。
在MySQL5.5及以前的版本，回滾日誌是跟資料字典一起放在ibdata檔案裡的，即使長事務最終提交，回滾段被清理，檔案也不會變小。比如資料只有20GB，而回滾段有200GB的庫，最終只好為了清理回滾段，重建整個庫。除了對回滾段的影響，長事務還佔用鎖資源，也可能拖垮整個庫。
事務的啟動方式
- 顯示啟動事務語句，begin或start transaction。配套的提交語句是commit，回滾語句是rollback。
- set autocommit=0，這個命令會將這個執行緒的自動提交關閉。意味著如果你只執行一個select語句，這個事務就啟動了，而且並不會自動提交。這個事務持續存在直到你主動執行commit或rollback語句，或者斷開連線。
有些客戶端連線框架會預設連線成功後先執行一個set autocommit=0的命令，這就導致接下來的查詢都在事務中，如果是長連線，就導致了意外的長事務。因此建議總是使用set autocommit=1，通過顯示語句的方式來啟動事務。
對於一個需要頻繁使用事務的業務，第二種方式每個事務在開始時都不需要主動執行一次“begin”，減少了語句的互動次數。如果你顧慮“多一次互動”的問題，建議使用commit work and chain語法。
在autocommit為1的情況下，用begin顯式啟動的事務，如果執行commit則提交事務，如果執行commit work and chain，則是提交事務並自動啟動下一個事務，這樣也省去了再次執行begin語句的開銷。同時帶來的好處是從程式開發的角度明確每個語句是否處於事務中。
你可以在information_schema庫的innodb_trx這個表查詢長事務，比如下面這個語句，由於查詢持續時間超過60s的事務：
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60
六、討論
前面說了系統裡面應該避免長事務，那麼有什麼方案來避免出現或者處理這種情況呢？
首先，從應用開發端來看：
- 確認是否使用了set_autocommit=0，這個確認工作可以在測試環境中開展，把MySQL的general_log開起來，然後隨便跑一個業務邏輯，通過general_log的日誌來確認；
- 確認是否有不必要的只讀事務。有些框架會習慣不管什麼語句先用begin/commit框起來。把好幾個select語句放到了事務中，這種只讀事務可以去掉；
- 業務連線資料庫時，根據業務本身的預估，通過SET MAX_EXECUTION_TIME命令，來控制每個語句執行的最長時間，避免單個語句意外執行太長時間。
其次，從資料庫端來看：
- 監控information_schema.Innodb_trx表，設定長事務閥值，超過就預警或kill；
- Percona的pt-kill工具不錯，推薦使用；
- 在業務功能測試階段要求輸出所有的general_log，分析日誌行為提前發現問題；
- 如果使用的是MySQL5.6或者更新版本，把innodb_undo_tablespaces設定為2（或者更大的值）。如果真出現大事務導致回滾段過大，這樣設定後清理起來更方便。