第六章鎖（學習筆記）-有解無憂

　　開發多用戶、資料庫驅動的應用時，最大的一個難點是：一方面要最大程度地利用資料庫地并發訪問，另外一方面還要確保每個用戶能以一致地方式讀取和修改資料，

　　1. 什么是鎖

　　鎖機制用于管理對共享資源地并發訪問，InnoDB存盤引擎會在行級別上對表資料上鎖，

　　2. lock與latch

　　latch是一種輕量級地鎖，分為mutex（互斥量）和rwlock（讀寫鎖），其目的是用來保證并發執行緒操作臨界資源地正確性，并且通常沒有死鎖檢測機制，

　　lock的物件是事務，用來鎖定的是資料庫中的物件，如表、頁、行，lock的物件僅在事務commit或rollback后進行釋放，另外，lock有死鎖機制，

　　3. InnoDB存盤引擎中的鎖

　　3.1 鎖的型別

共享鎖（S lock）允許事務讀一行資料
排他鎖（X lock）允許事務洗掉或更新一行資料

　　InnoDB存盤引擎還支持一種額外的鎖方式，即意向鎖（Intension lock），意向鎖將鎖定的物件分為多個層次，意向鎖意味著事務希望在更細粒度上進行加鎖，　　

　　若將上鎖的物件看成一個樹，那么對對下層的物件上鎖（最細粒度的物件上鎖），需要首先對粗粒度的物件上鎖，如下圖所示，如果需要對頁上的記錄r上X鎖，需要對資料庫A、表、頁上意向鎖IX，最后對記錄r上X鎖，

　　鎖的兼容性如下圖所示，

　　3.2 一致性非鎖定讀

　　一致性非鎖定讀（consistent nonlocking read）指InnoDB存盤引擎通過行多版本控制的方式來讀取當前執行時間資料庫中的行資料，如果讀取的行正在執行DELETE或UPDATE操作，這時，讀取操作不會等待行上鎖的釋放，InnoDB存盤引擎會去讀取行的一個快照資料，非鎖定讀機制可以極大的提高資料庫的并發性，

　　讀取的快照資料來自undo段，undo用來在事務中回滾資料，因此快照資料本身沒有額外的開銷，由圖中可以看到，一個行記錄可能有不止一個快照資料，一般稱這種技術為行多版本技術，由此帶來的并發控制，稱之為多版本并發控制（multi version concurrency control MVCC），

　　在READ COMMITED 事務隔離級別下，對于快照資料，一致性非鎖定讀總是讀取非鎖定行的最新一份快照資料，在REPEATABLE READ 事務隔離級別下，對于快照資料，一致性非鎖定讀總是讀取事務開始時的行資料版本，

　　如上表所示執行，在時間點5，兩種隔離模式，得到的結果一樣，即id = 1; 在時間點7，兩種隔離模式，會得到不同的結果，READ COMMITED 得到 Empty Set (讀取最新的行資料快照)， REPEATABLE READ仍是id =1（事務開始時的行資料），

　　3.3 一致性鎖定讀

　　在某些情況下，用戶需要顯式地對資料庫讀取操作進行加鎖以保證資料邏輯的一致性，InnoDB存盤引擎對于SELECT陳述句支持兩種一致性地鎖定讀（locking read）操作：

SELECT.....FOR UPDATE （對讀取的行加X鎖，其他事務不能對已鎖定的行加上任何鎖）
SELECT.....LOCK IN SHARE MODE （對讀取的行加S鎖，其他事務可以對被鎖定地行加S鎖，但是加X鎖，則會被阻塞）

　　此外，這兩種操作必須在一個事務中，當事務提交了，鎖也就釋放了，因此，在使用上述兩句SELECT鎖定陳述句時，務必加上BEGIN, START TRANSACTION 或者SET AUTOCOMMIT=0，

　　3.4 外鍵和鎖

　　對于外鍵地插入或更新，首先需要查詢父表中的記錄，即SELECT父表，但是對于父表的SELECT操作，不是使用一致性非鎖定讀的方式，因為這樣會發生資料不一致的問題，這時，使用的是SELECT...LOCK IN SHARE MODE方式，即主動對父表加一個S鎖，如果這時父表上已經有了X鎖，子表上的操作會被阻塞，如下表所示，

　　4 鎖的演算法

　　4.1 行鎖的三種演算法

　　InnoDB存盤引擎有三種行鎖的演算法：

Record Lock：單個行記錄上的鎖（總是會鎖住索引記錄，如果存盤引擎表在建立的時候沒有設定任何一個索引，那么這時InnoDB存盤引擎會使用隱式的主鍵來進行鎖定）
Gap Lock：間隙鎖，鎖定一個范圍，但不包含記錄本身
Next-Key-Lock：Gap Lock + Record Lock

　　InnoDB對行的查詢都是采用Next-Key-Lock演算法，該演算法可以解決Phantom Problem，假如一個索引有10，11，13，20這四個值，那么被索引的區間為：（-∞， 10], (10, 11], (11, 13], (13, 20], (20, +∞)

　　當查詢的列是唯一索引時，會降級為Record Lock，若是輔助索引，情況會不太一樣，先創建如下測驗表z:

　　現在會話A中執行上面的SQL陳述句，由于b列是輔助索引，Next-Key-Lock演算法會鎖定（1，3] ，另外，特別需要注意的是，InnoDB存盤引擎還會對輔助索引下個鍵值（即6）加上gap lock，所以鎖定的輔助索引為1 2 3 4 5，所以運行下面的SQL陳述句都會被阻塞，

　　而下面的SQL陳述句則不會被阻塞：

　　4.2 解決Phantom Problem

　　在默認的事務隔離級別下，即REPEATABLE READ下，InnoDB存盤引擎采用Next-Key-Locking機制來避免Phantom Problem（幻像問題），

　　Phantom Problem是指在同一事務下，連續執行兩次同樣的SQL陳述句可能導致不同的結果，第二次的SQL陳述句可能回傳之前不存在的行，

　　假設表由1、2、5三個值組成，若執行如下的SQL陳述句：

　　會話A在時間3 和 7 執行的SQL陳述句會得到不同的結果，為了避免Phantom Problem，對于上述SQL陳述句，其鎖住的不是5這個值，而是對（2，∞）這個范圍加了X鎖，因此，對于這個范圍的插入都是不被允許的，從而避免了Phantom Problem，

　　5. 鎖問題

　　5.1 臟讀

　　臟資料是指事務對緩沖池中行記錄進行了修改，但是還沒有提交的資料，如果讀到了臟資料，即一個事務可以讀到另外一個事務中未提交的資料，則顯然違反了資料庫的隔離性（臟讀），下表是一個臟讀的例子，

　　READ UNCOMMITTED可以應用在一些比較特殊的情況，例如，replication環境中的slave節點，并且在該slave上的查詢并不需要特別精確的回傳值

　　5.2 不可重復讀

　　不可重復讀是指在一個事務內多次讀取同一資料集合，在這個事務還沒有結束時，另外一個事務也訪問同一資料集合，并做了一些DML操作，因此，在第一個事務中的兩次讀資料之間，由于第二個事務的修改，那么第一個事務兩次讀到的資料可能是不一樣的，即一個事務內兩次讀到的資料是不一樣的，即不可重復讀，不可重復讀的示例如下表所示，

　　InnoDB存盤引擎的默認事務隔離級別是READ REPEATABLE，采用Next-Key-Lock演算法，避免了不可重復讀的現象，

　　5.3 丟失更新

　　一個事務的更新操作會被另一個事務的更新操作所覆寫，從而導致資料的不一致，出現下面的情況時，就會發生丟失更新：

　　1）事務T1查詢一行資料，放入本地記憶體，并顯示給一個終端用戶User1

　　2）事務T2也查詢該行資料，并將取得的資料顯示給終端用戶User2

　　3） User1修改該行記錄，更新資料庫并提交

　　4） User2修改該行記錄，更新并提交資料

　　要避免丟失更新發生，需要事務在這種情況下的操作變成串行化，而不是并行的操作，如下表所示：

　　6. 阻塞

　　因為不同鎖之間的兼容性關系，在有些時刻一個事務中的鎖需要等待另一個事務中的鎖釋放它所占用的資源，這就是阻塞，

　　在InnoDB存盤引擎中，引數innodb_lock_wait_timeout用來控制等待的時間（默認50s，動態引數，可以在運行時調整），innodb_on_timeout（靜態引數，不可在啟動后，修改）用來設定是否在等待超時時，對進行中的事務進行回滾操作（默認是OFF，代表不回滾），當做默認設定時，可能存在如下問題：