MySQL - 事務的啓動 / 設置 / 鎖 / 解鎖——入門

廢話

本篇的名字簡直能夠起成《事務操做：從入門到放棄》。

力圖解決：在MySQL 5.5 版本及更高版本時，使用事務的完整流程和細節記錄，而無需面對互聯網上紛繁零散的事務筆記。

實踐 - 基礎

首先，在你的空數據庫上（譬如Test預留數據庫），建立一個test表，有id和text(varchar 50)兩個字段。

請開啓兩個MySQL操做端，分別依次鍵入：

A端	B端
SET AUTOCOMMIT=0	SET AUTOCOMMIT=0
SELECT text FROM test WHERE id = 1	不輸入
UPDATE test SET text='UioSun' WHERE id = 1;	UPDATE test SET text='UioYang' WHERE id = 1;

注意你的查詢提示欄，你能發現：在A端未提交以前，默認狀態下，B端的UPDATE是沒有反饋的——被掛起。等待一段時間後，你能收到關於Transaction失敗的消息。

這種錯誤狀態被稱爲死鎖，你能夠經過解鎖相關的內容，來Kill it。

上述是很極端的狀況，正常來講，事務是經過自動插入來完成，基本上能夠避免死鎖狀況。

這就是事務的基礎演示，最後，經過ROLLBACK或COMMIT，你能夠完成事務的結束。

實踐 - 鎖

在上一部分，你完成了一個事務的基礎流程，啓動、進行、並最終獲得結果（或許是意外結果）。
至少我在上一部分結尾處，腦海中有兩個問題：

1. 我聽過事務的鎖，它經過鎖完成獨享目標，並在完成修改後釋放它的獨享權，但我該如何設置它的級別？

2. 鎖的阻塞時間爲多久？我如何檢測它？

固然，爲了另外一種思路的編程玩家，我也將在本節末尾放上當前支持鎖的優缺比較。

---

行級鎖，頁級鎖，表級鎖。聞其名知其意，比較少見的是：頁級鎖，它鎖定的是一組相鄰數據。

而MySQL的不一樣引擎，對鎖級別支持是不同的，以最經常使用的InnoDB爲表明，默認採用行級鎖，也支持表級鎖，但這是有條件的，只有在針對索引SQL操做時，纔會使用行級鎖，不然這個操做將採起表級鎖。

表級鎖鎖定的數量最多，佔據內存最多，但有在作內部處理時中，它的操做速度是至關快的，並且幾乎不存在死鎖問題，因此在中大型內部處理機制中，表級鎖的應用場景大於行級鎖。

行級鎖又分爲共享鎖和獨佔鎖（排它鎖，翻譯差別），容許讀取的共享鎖是默認鎖，而獨佔鎖是不容許讀寫的徹底佔有——廢話。

共享鎖（S）：容許一個事務去讀一行，阻止其餘事務得到相同數據集的排他鎖。
排他鎖（X)：容許得到排他鎖的事務更新數據，阻止其餘事務取得相同數據集的讀寫。
另外，爲了容許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB還有兩種內部使用的意向鎖（Intention Locks），這兩種意向鎖都是表鎖。
意向共享鎖（IS）：事務打算給數據行加行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。
意向排他鎖（IX）：事務打算給數據行加行排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。

頁級鎖（間隙鎖）

@gaoyulong 表示：間隙鎖被吃啦？

對此我表示抱歉，以前一直了解的都是頁級鎖（也就是間隙鎖），恰恰頁級鎖在互聯網上的信息又不夠豐富，因此就沒考慮到。

頁級鎖是個很重要的鎖，它會鎖定一組數據，但這個鎖並非那麼好用（更多的考慮是安全性）。

對於鍵值在條件範圍內但並不存在的記錄，叫作「間隙（GAP)」，InnoDB也會對這個「間隙」加鎖，這種鎖機制就是所謂的間隙鎖（Next-Key鎖）。

InnoDB使用間隙鎖的目的，一方面是爲了防止幻讀，以知足相關隔離級別的要求，對一個AutoID 100條數據的表作ID爲102的查詢，要是不使用間隙鎖，若是其餘事務插入了ID大於100的任何記錄，那麼本事務若是再次執行上述語句，就會發生幻讀；另一方面，是爲了知足其恢復和複製的須要。

本段內容源於：間隙鎖（Next-Key鎖） - xiaobluesky

在此基礎上，若是在查詢鎖表時，對不存在ID進行Insert操做，將致使等待阻塞。

額外的鎖

除了DB自己分類外，在框架層面，還有樂觀鎖與悲觀鎖之分。注意層面，這種鎖屬於應用程序設計的鎖，而非數據庫設計的鎖。

以我最熟悉的Yii 2框架爲例。簡述：

1. 樂觀鎖就是一個可對比序列號，但存在高頻併發時的對比錯位 BUG；

2. 悲觀鎖就是一個嚴謹可對比序列號，並提供解鎖功能。事實上，因爲悲觀鎖的使用複雜度（我沒看出來），Yii 2並無提供悲觀鎖功能。

解鎖

說完鎖，咱們確定須要一個解鎖機制，腦海裏突然蹦出冷段子：一人去買門鎖，安好了才發現，這門只能從外面開，進去鎖門就出不來了。

很冷吧。沒有解鎖機制的事務處理系統，是一個只能進，不能出的事務處理系統——死鎖儘管會自動解鎖，但反饋時間是一個很剛性的設置。

先說這個很剛的設置，若是你想修改它，能夠去 my.ini 文件的innodb_lock_wait_timeout這一行，默認爲50
s的等待時間。

應用層面的鎖能夠經過校對序列號來自行解鎖，而MySQL層面的鎖，能夠經過information_scheme的PROCESSLIST表，來完成解鎖——確認沒法完成事務。

這裏說一下PROCESSLIST表，當一個關閉自動提交的事務已經啓動，另外一個同類事務也啓動，雙方衝突後，在這個表內是存在衝突SQL Status，你能夠本身去觀察。

最後：不管解鎖機制多麼健全，死鎖自己是代碼邏輯引發的，不修正/優化代碼邏輯，單純的解鎖機制不過是對系統的額外負擔。

解決方案很簡單：本身寫一個簡單的Log功能，將全部觸發解鎖機制的狀況，記錄在Log裏，自行優化。

隔離

配合鎖機制的就是隔離機制，它能夠儘量有效的設置：事務間的可見度。

1. 讀取未提交（RU，Read Uncommitted）：最低隔離，問題是髒讀（未被提交的UPDATE，仍然可被讀取）。

2. 讀取提交（RC，Read Committed）：語句提交之後即執行了COMMIT之後別的事務就能讀到這個改變. 問題：不可重複讀（同事務時，先後讀取到不一致數據）。

3. 可重複讀（RR，Repeatable Read）：在同一個事務裏面前後執行同一個查詢語句的時候,獲得的結果是同樣的，問題：幻讀（併發事務同時處理同內容，並致使一方內容覆蓋了另外一方，令對方感受出現了幻覺）。

4. 序列化（S，Serializable）：在這個級別下，全部的事務的完整性都被保留，意味着全部的事務均可以被序列化的執行，只有當兩個事務之間沒有任務衝突時，才能併發的執行。

四個級別中，高級隔離不會遇到比本身低級隔離的問題，但隔離級別越高，對併發的損失性越高。

MySQL默認採用RR級別。

題外

提到鎖，就想到之前作過的秒殺後端，當時的處理機制很簡單，時間戳 + 事務。

時光荏苒，如今回頭看，突然發現有一些改進的地方，一筆帶過：秒殺最大數量 緩存對比 → 服務器端 微秒級時間戳 + 事務/悲觀鎖 插入 + 插入失敗 緩存隊列及二次插入嘗試，這樣已經可以解決極大程度的併發問題了。

若是這樣都會出現重複插入問題，那按我目前的水準，在應用層面是解決不了了。