如何保證資料並行存取的一致性、有效性是所有資料庫必須解決的一個問題，鎖衝突也是影響資料庫並行存取效能的一個重要因素。從這個角度來說，鎖對資料庫而言顯得尤其重要，也更加複雜。

MySQL鎖概述

相對其他資料庫而言，MySQL的鎖機制比較簡單，其最顯著的特點是不同的儲存引擎支援不同的鎖機制。
比如

MyISAM和MEMORY儲存引擎採用的是表級鎖（table-level locking）。

InnoDB儲存引擎既支援行級鎖（row-level locking），也支援表級鎖，但預設情況下是採用行級鎖。

MySQL這3種鎖的特性可大致歸納如下

表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高,並行度最低。

行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低,並行度也最高。

頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並行度一般。

僅從鎖的角度來說：表級鎖更適合於以查詢為主，只有少量按索引條件更新資料的應用，如Web應用；而行級鎖則更適合於有大量按索引條件並行更新少量不同資料，同時又有並行查詢的應用，如一些線上事務處理（OLTP）系統。下面幾節我們重點介紹MySQL表鎖和 InnoDB行鎖的問題。

MyISAM表鎖

MyISAM儲存引擎只支援表鎖，這也是MySQL開始幾個版本中唯一支援的鎖型別。隨著應用對事務完整性和並行性要求的不斷提高，MySQL才開始開發基於事務的儲存引擎，後來慢慢出現了支援頁鎖的BDB儲存引擎和支援行鎖的InnoDB儲存引擎（實際 InnoDB是單獨的一個公司，現在已經被Oracle公司收購）。但是MyISAM的表鎖依然是使用最為廣泛的鎖型別。本節將詳細介紹MyISAM表鎖的使用。

查詢表級鎖爭用情況

可以通過檢查table_locks_waited和table_locks_immediate狀態變數來分析系統上的表鎖定爭奪：

mysql> show status like 'table%';

| Variable_name | Value |

| Table_locks_immediate | 2979 |

| Table_locks_waited | 0 |

2 rows in set (0.00 sec))

如果Table_locks_waited的值比較高，則說明存在著較嚴重的表級鎖爭用情況。

MySQL表級鎖的鎖模式

MySQL的表級鎖有兩種模式：表共用讀鎖（Table Read Lock）和表獨佔寫鎖（Table Write Lock）。

MyISAM表的讀操作，不會阻塞其他使用者對同一表的讀請求，但會阻塞對同一表的寫請求；
MyISAM表的寫操作，則會阻塞其他使用者對同一表的讀和寫操作；
MyISAM表的讀操作與寫操作之間，以及寫操作之間是序列的；
當一個執行緒獲得對一個表的寫鎖後，只有持有鎖的執行緒可以對錶進行更新操作。其他執行緒的讀、寫操作都會等待，直到鎖被釋放為止。

獲得表film_text的WRITE鎖定

mysql> lock table film_text write;

Query OK, 0 rows affected (0.00 sec)

當前session對鎖定表的查詢、更新、插入操作都可以執行：

mysql> select film_id,title from film_text where film_id = 1001;

| film_id | title |

| 1001 | Update Test |

1 row in set (0.00 sec)

mysql> insert into film_text (film_id,title) values(1003,'Test');

Query OK, 1 row affected (0.00 sec)

mysql> update film_text set title = 'Test' where film_id = 1001;

Query OK, 1 row affected (0.00 sec)

Rows matched: 1 Changed: 1 Warnings: 0

其他session對鎖定表的查詢被阻塞，需要等待鎖被釋放：

mysql> select film_id,title from film_text where film_id = 1001;

等待

釋放鎖：

mysql> unlock tables;

Query OK, 0 rows affected (0.00 sec)

等待

Session2獲得鎖，查詢返回：

mysql> select film_id,title from film_text where film_id = 1001;

| film_id | title |

| 1001 | Test |

1 row in set (57.59 sec)

如何加表鎖？

MyISAM在執行查詢語句（SELECT）前，會自動給涉及的所有表加讀鎖，在執行更新操作（UPDATE、DELETE、INSERT等）前，會自動給涉及的表加寫鎖，這個過程並不需要使用者干預，因此，使用者一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在範例中，顯式加鎖基本上都是為了方便而已，並非必須如此。

給MyISAM表顯示加鎖，一般是為了在一定程度模擬事務操作，實現對某一時間點多個表的一致性讀取。例如，有一個訂單表orders，其中記錄有各訂單的總金額total，同時還有一個訂單明細表order_detail，其中記錄有各訂單每一產品的金額小計 subtotal，假設我們需要檢查這兩個表的金額合計是否相符，可能就需要執行如下兩條SQL：

Select sum(total) from orders;

Select sum(subtotal) from order_detail;

這時，如果不先給兩個表加鎖，就可能產生錯誤的結果，因為第一條語句執行過程中，order_detail表可能已經發生了改變。因此，正確的方法應該是：

Lock tables orders read local, order_detail read local;

Select sum(total) from orders;

Select sum(subtotal) from order_detail;

Unlock tables;

要特別說明以下兩點內容。

上面的例子在LOCK TABLES時加了「local」選項，其作用就是在滿足MyISAM表並行插入條件的情況下，允許其他使用者在表尾並行插入記錄，有關MyISAM表的並行插入問題，後面還會進一步介紹。

在用LOCK TABLES給表顯式加表鎖時，必須同時取得所有涉及到表的鎖，並且MySQL不支援鎖升級。也就是說，在執行LOCK TABLES後，只能存取顯式加鎖的這些表，不能存取未加鎖的表；同時，如果加的是讀鎖，那麼只能執行查詢操作，而不能執行更新操作。其實，在自動加鎖的情況下也基本如此，MyISAM總是一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會出現死鎖（Deadlock Free）的原因。

一個session使用LOCK TABLE命令給表film_text加了讀鎖，這個session可以查詢鎖定表中的記錄，但更新或存取其他表都會提示錯誤；同時，另外一個session可以查詢表中的記錄，但更新就會出現鎖等待。

當使用LOCK TABLES時，不僅需要一次鎖定用到的所有表，而且，同一個表在SQL語句中出現多少次，就要通過與SQL語句中相同的別名鎖定多少次，否則也會出錯！

舉例說明如下。

（1）對actor表獲得讀鎖：

mysql> lock table actor read;

Query OK, 0 rows affected (0.00 sec)

（2）但是通過別名存取會提示錯誤：

mysql> select a.first_name,a.last_name,b.first_name,b.last_name from actor a,actor b where a.first_name = b.first_name and a.first_name = 'Lisa' and a.last_name = 'Tom' and a.last_name <> b.last_name;

ERROR 1100 (HY000): Table 'a' was not locked with LOCK TABLES

（3）需要對別名分別鎖定：

mysql> lock table actor as a read,actor as b read;

Query OK, 0 rows affected (0.00 sec)

（4）按照別名的查詢可以正確執行：

mysql> select a.first_name,a.last_name,b.first_name,b.last_name from actor a,actor b where a.first_name = b.first_name and a.first_name = 'Lisa' and a.last_name = 'Tom' and a.last_name <> b.last_name;

| first_name | last_name | first_name | last_name |

| Lisa | Tom | LISA | MONROE |

1 row in set (0.00 sec)

並行插入（Concurrent Inserts）

上文提到過MyISAM表的讀和寫是序列的，但這是就總體而言的。在一定條件下，MyISAM表也支援查詢和插入操作的並行進行。

MyISAM儲存引擎有一個系統變數concurrent_insert，專門用以控制其並行插入的行為，其值分別可以為0、1或2。

當concurrent_insert設定為0時，不允許並行插入。

當concurrent_insert設定為1時，如果MyISAM表中沒有空洞（即表的中間沒有被刪除的行），MyISAM允許在一個程序讀表的同時，另一個程序從表尾插入記錄。這也是MySQL的預設設定。

當concurrent_insert設定為2時，無論MyISAM表中有沒有空洞，都允許在表尾並行插入記錄。

可以利用MyISAM儲存引擎的並行插入特性，來解決應用中對同一表查詢和插入的鎖爭用。例如，將concurrent_insert系統變數設為2，總是允許並行插入；同時，通過定期在系統空閒時段執行 OPTIMIZE TABLE語句來整理空間碎片，收回因刪除記錄而產生的中間空洞。有關OPTIMIZE TABLE語句的詳細介紹，可以參見第18章中「兩個簡單實用的優化方法」一節的內容。

MyISAM的鎖排程

前面講過，MyISAM儲存引擎的讀鎖和寫鎖是互斥的，讀寫操作是序列的。那麼，一個程序請求某個 MyISAM表的讀鎖，同時另一個程序也請求同一表的寫鎖，MySQL如何處理呢？答案是寫程序先獲得鎖。不僅如此，即使讀請求先到鎖等待佇列，寫請求後到，寫鎖也會插到讀鎖請求之前！這是因為MySQL認為寫請求一般比讀請求要重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原因，因為，大量的更新操作會造成查詢操作很難獲得讀鎖，從而可能永遠阻塞。這種情況有時可能會變得非常糟糕！幸好我們可以通過一些設定來調節MyISAM 的排程行為。

通過指定啟動引數low-priority-updates，使MyISAM引擎預設給予讀請求以優先的權利。

通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連線發出的更新請求優先順序降低。

通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先順序。

雖然上面3種方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如使用者登入系統）中，讀鎖等待嚴重的問題。

另外，MySQL也提供了一種折中的辦法來調節讀寫衝突，即給系統引數max_write_lock_count設定一個合適的值，當一個表的讀鎖達到這個值後，MySQL就暫時將寫請求的優先順序降低，給讀程序一定獲得鎖的機會。

上面已經討論了寫優先排程機制帶來的問題和解決辦法。這裡還要強調一點：一些需要長時間執行的查詢操作，也會使寫程序「餓死」！因此，應用中應儘量避免出現長時間執行的查詢操作，不要總想用一條SELECT語句來解決問題，因為這種看似巧妙的SQL語句，往往比較複雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的「分解」，使每一步查詢都能在較短時間完成，從而減少鎖衝突。如果複雜查詢不可避免，應儘量安排在資料庫空閒時段執行，比如一些定期統計可以安排在夜間執行。

InnoDB鎖

InnoDB與MyISAM的最大不同有兩點：一是支援事務（TRANSACTION）；二是採用了行級鎖。行級鎖與表級鎖本來就有許多不同之處，另外，事務的引入也帶來了一些新問題。下面我們先介紹一點背景知識，然後詳細討論InnoDB的鎖問題。

1.事務（Transaction）及其ACID屬性

事務是由一組SQL語句組成的邏輯處理單元，事務具有以下4個屬性，通常簡稱為事務的ACID屬性。

（Atomicity）原子性：事務是一個原子操作單元，其對資料的修改，要麼全都執行，要麼全都不執行。

（Consistent）一致性：在事務開始和完成時，資料都必須保持一致狀態。這意味著所有相關的資料規則都必須應用於事務的修改，以保持資料的完整性；事務結束時，所有的內部資料結構（如B樹索引或雙向連結串列）也都必須是正確的。

（Isolation）隔離性：資料庫系統提供一定的隔離機制，保證事務在不受外部並行操作影響的「獨立」環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的，反之亦然。

（Durable）永續性：事務完成之後，它對於資料的修改是永久性的，即使出現系統故障也能夠保持。

銀行轉帳就是事務的一個典型例子。

2.並行事務處理帶來的問題

相對於序列處理來說，並行事務處理能大大增加資料庫資源的利用率，提高資料庫系統的事務吞吐量，從而可以支援更多的使用者。但並行事務處理也會帶來一些問題，主要包括以下幾種情況。

更新丟失（Lost Update）：當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，由於每個事務都不知道其他事務的存在，就會發生丟失更新問題－－最後的更新覆蓋了由其他事務所做的更新。例如，兩個編輯人員製作了同一檔案的電子副本。每個編輯人員獨立地更改其副本，然後儲存更改後的副本，這樣就覆蓋了原始檔案。最後儲存其更改副本的編輯人員覆蓋另一個編輯人員所做的更改。如果在一個編輯人員完成並提交事務之前，另一個編輯人員不能存取同一檔案，則可避免此問題。

髒讀（Dirty Reads）：一個事務正在對一條記錄做修改，在這個事務完成並提交前，這條記錄的資料就處於不一致狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些「髒」資料，並據此做進一步的處理，就會產生未提交的資料依賴關係。這種現象被形象地叫做"髒讀"。

不可重複讀（Non-Repeatable Reads）：一個事務在讀取某些資料後的某個時間，再次讀取以前讀過的資料，卻發現其讀出的資料已經發生了改變、或某些記錄已經被刪除了！這種現象就叫做「不可重複讀」。

幻讀（Phantom Reads）：一個事務按相同的查詢條件重新讀取以前檢索過的資料，卻發現其他事務插入了滿足其查詢條件的新資料，這種現象就稱為「幻讀」。

3.事務隔離級別

在上面講到的並行事務處理帶來的問題中，「更新丟失」通常是應該完全避免的。但防止更新丟失，並不能單靠資料庫事務控制器來解決，需要應用程式對要更新的資料加必要的鎖來解決，因此，防止更新丟失應該是應用的責任。

「髒讀」、「不可重複讀」和「幻讀」，其實都是資料庫讀一致性問題，必須由資料庫提供一定的事務隔離機制來解決。資料庫實現事務隔離的方式，基本上可分為以下兩種。

一種是在讀取資料前，對其加鎖，阻止其他事務對資料進行修改。

另一種是不用加任何鎖，通過一定機制生成一個資料請求時間點的一致性資料快照（Snapshot)，並用這個快照來提供一定級別（語句級或事務級）的一致性讀取。從使用者的角度來看，好像是資料庫可以提供同一資料的多個版本，因此，這種技術叫做資料多版本並行控制（MultiVersion Concurrency Control，簡稱MVCC或MCC），也經常稱為多版本資料庫。

一致性讀，又稱為快照讀。使用的是MVCC機制讀取undo中的已經提交的資料。所以它的讀取是非阻塞的。

一致性讀肯定是讀取在某個時間點已經提交了的資料，有個特例：本事務中修改的資料，即使未提交的資料也可以在本事務的後面部分讀取到。一致性讀是指普通的select語句，不帶 for update, in share mode 等等子句。使用的是undo中的提交的資料，不需要使用鎖(MDL除外)。而當前讀，是指update, delete, select for update, select in share mode等等語句進行的讀，它們讀取的是資料庫中的最新的資料，並且會鎖住讀取的行和gap(RR隔離時)。如果不能獲得鎖，則會一直等待，直到獲得或者超時。

資料庫的事務隔離越嚴格，並行副作用越小，但付出的代價也就越大，因為事務隔離實質上就是使事務在一定程度上 「序列化」進行，這顯然與「並行」是矛盾的。同時，不同的應用對讀一致性和事務隔離程度的要求也是不同的，比如許多應用對「不可重複讀」和「幻讀」並不敏感，可能更關心資料並行存取的能力。

為了解決「隔離」與「並行」的矛盾，ISO/ANSI SQL92定義了4個事務隔離級別，每個級別的隔離程度不同，允許出現的副作用也不同，應用可以根據自己的業務邏輯要求，通過選擇不同的隔離級別來平衡 「隔離」與「並行」的矛盾。表20-5很好地概括了這4個隔離級別的特性。

各具體資料庫並不一定完全實現了上述4個隔離級別Oracle只提供Read committed和Serializable兩個標準隔離級別，另外還提供自己定義的Read only隔離級別；SQL Server除支援上述ISO/ANSI SQL92定義的4個隔離級別外，還支援一個叫做「快照」的隔離級別，但嚴格來說它是一個用MVCC實現的Serializable隔離級別。

MySQL 支援全部4個隔離級別，但在具體實現時，有一些特點，比如在一些隔離級別下是採用MVCC一致性讀，但某些情況下又不是，這些內容在後面的章節中將會做進一步介紹。

4.獲取InnoDB行鎖爭用情況

可以通過檢查InnoDB_row_lock狀態變數來分析系統上的行鎖的爭奪情況。

mysql> show status like 'innodb_row_lock%';

| Variable_name | Value |

| InnoDB_row_lock_current_waits | 0 |

| InnoDB_row_lock_time | 0 |

| InnoDB_row_lock_time_avg | 0 |

| InnoDB_row_lock_time_max | 0 |

| InnoDB_row_lock_waits | 0 |

5 rows in set (0.01 sec)

如果發現鎖爭用比較嚴重，如InnoDB_row_lock_waits 和 InnoDB_row_lock_time_avg的值比較高，還可以通過設定InnoDB Monitors來進一步觀察發生鎖衝突的表、資料行等，並分析鎖爭用的原因。

具體方法如下：

mysql> CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;

Query OK, 0 rows affected (0.14 sec)

然後就可以用下面的語句來進行檢視：

mysql> Show innodb status\G;

監視器可以通過發出下列語句來停止檢視：

mysql> DROP TABLE innodb_monitor;

Query OK, 0 rows affected (0.05 sec)

設定監視器後，在SHOW INNODB STATUS的顯示內容中，會有詳細的當前鎖等待的資訊，包括表名、鎖型別、鎖定記錄的情況等，便於進行進一步的分析和問題的確定。開啟監視器以後，預設情況下每15秒會向紀錄檔中記錄監控的內容，如果長時間開啟會導致.err檔案變得非常的巨大，所以使用者在確認問題原因之後，要記得刪除監控表以關閉監視器，或者通過使用「--console」選項來啟動伺服器以關閉寫紀錄檔檔案。

5. InnoDB的行鎖模式及加鎖方法

InnoDB實現了以下兩種型別的行鎖。

共用鎖（S）：允許一個事務去讀一行，阻止其他事務獲得相同資料集的排他鎖。

排他鎖（X）：允許獲得排他鎖的事務更新資料，阻止其他事務取得相同資料集的共用讀鎖和排他寫鎖。

另外，為了允許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB還有兩種內部使用的意向鎖（Intention Locks），

這兩種意向鎖都是表鎖。

意向共用鎖（IS）：事務打算給資料行加行共用鎖，事務在給一個資料行加共用鎖前必須先取得該表的IS鎖。

意向排他鎖（IX）：事務打算給資料行加行排他鎖，事務在給一個資料行加排他鎖前必須先取得該表的IX鎖。

如果一個事務請求的鎖模式與當前的鎖相容，InnoDB就將請求的鎖授予該事務；反之，如果兩者不相容，該事務就要等待鎖釋放。

意向鎖是InnoDB自動加的，不需使用者干預。

總結如下：

1. 對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及資料集加排他鎖（X）；

2. 對於普通SELECT語句，InnoDB不會加任何鎖；

3. 事務可以通過以下語句顯示給記錄集加共用鎖或排他鎖。

共用鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。

排他鎖（X）：SELECT * FROM table_name WHERE ... FOR UPDATE。

用SELECT ... IN SHARE MODE獲得共用鎖，主要用在需要資料依存關係時來確認某行記錄是否存在，並確保沒有人對這個記錄進行UPDATE或者DELETE操作。

但是如果當前事務也需要對該記錄進行更新操作，則很有可能造成死鎖，對於鎖定行記錄後需要進行更新操作的應用，應該使用SELECT... FOR UPDATE方式獲得排他鎖。

6. InnoDB行鎖實現方式

InnoDB行鎖是通過給索引上的索引項加鎖來實現的，這一點MySQL與Oracle不同，後者是通過在資料塊中對相應資料行加鎖來實現的。

InnoDB這種行鎖實現特點意味著：只有通過索引條件檢索資料，InnoDB才使用行級鎖，否則，InnoDB將使用表鎖！

在實際應用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導致大量的鎖衝突，從而影響並行效能。

（1） 在不通過索引條件查詢的時候，InnoDB確實使用的是表鎖，而不是行鎖。

（2）由於MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是存取不同行的記錄，

但是如果是使用相同的索引鍵，是會出現鎖衝突的。應用設計的時候要注意這一點。

（3）當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，

另外，不論是使用主鍵索引、唯一索引或普通索引，InnoDB都會使用行鎖來對資料加鎖。

（4）即便在條件中使用了索引欄位，但是否使用索引來檢索資料是由MySQL通過判斷不同執行計劃的代價來決定的，如果MySQL認為全表掃描效率更高，比如對一些很小的表，它就不會使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖衝突時，別忘了檢查SQL的執行計劃，以確認是否真正使用了索引。關於MySQL在什麼情況下不使用索引的詳細討論，參見本章「索引問題」一節的介紹。

7. 間隙鎖（Next-Key鎖）

當我們用範圍條件而不是相等條件檢索資料，並請求共用或排他鎖時，InnoDB會給符合條件的已有資料記錄的索引項加鎖；對於鍵值在條件範圍內但並不存在的記錄，叫做「間隙（GAP）」，InnoDB也會對這個「間隙」加鎖，這種鎖機制就是所謂的間隙鎖（Next-Key鎖）。假如emp表中只有101條記錄，其empid的值分別是 1,2,...,100,101 下面的SQL：

Select * from emp where empid > 100 for update;

是一個範圍條件的檢索，InnoDB不僅會對符合條件的empid值為101的記錄加鎖，也會對empid大於101（這些記錄並不存在）的「間隙」加鎖。InnoDB使用間隙鎖的目的，一方面是為了防止幻讀，以滿足相關隔離級別的要求，對於上面的例子，要是不使用間隙鎖，如果其他事務插入了empid大於100的任何記錄，那麼本事務如果再次執行上述語句，就會發生幻讀；另外一方面，是為了滿足其恢復和複製的需要。有關其恢復和複製對鎖機制的影響，以及不同隔離級別下InnoDB使用間隙鎖的情況，在後續的章節中會做進一步介紹。

很顯然，在使用範圍條件檢索並鎖定記錄時，InnoDB這種加鎖機制會阻塞符合條件範圍內鍵值的並行插入，這往往會造成嚴重的鎖等待。因此，在實際應用開發中，尤其是並行插入比較多的應用，我們要儘量優化業務邏輯，儘量使用相等條件來存取更新資料，避免使用範圍條件。

特別說明的是，InnoDB除了通過範圍條件加鎖時使用間隙鎖外，如果使用相等條件請求給一個不存在的記錄加鎖，InnoDB也會使用間隙鎖！

恢復和複製的需要，對InnoDB鎖機制的影響

MySQL通過BINLOG記錄執行成功的INSERT、UPDATE、DELETE等更新資料的SQL語句，並由此實現MySQL資料庫的恢復和主從複製。MySQL的恢復機制（複製其實就是在Slave Mysql不斷做基於BINLOG的恢復）有以下特點。

一是MySQL的恢復是SQL語句級的，也就是重新執行BINLOG中的SQL語句。這與Oracle資料庫不同，Oracle是基於資料庫檔案塊的。

二是MySQL的BINLOG是按照事務提交的先後順序記錄的，恢復也是按這個順序進行的。這點也與Oralce不同，Oracle是按照系統更新號（System Change Number，SCN）來恢復資料的，每個事務開始時，Oracle都會分配一個全域性唯一的SCN，SCN的順序與事務開始的時間順序是一致的。

從上面兩點可知，MySQL的恢復機制要求：在一個事務未提交前，其他並行事務不能插入滿足其鎖定條件的任何記錄，也就是不允許出現幻讀，這已經超過了ISO/ANSI SQL92「可重複讀」隔離級別的要求，實際上是要求事務要序列化。

另外，對於「insert into target_tab select * from source_tab where ...」和「create table new_tab ...select ... From source_tab where ...(CTAS)」這種SQL語句，使用者並沒有對source_tab做任何更新操作，但MySQL對這種SQL語句做了特別處理。

（這裡InnoDB卻給source_tab加了共用鎖，並沒有使用多版本資料一致性讀技術！）

在上面的例子中，只是簡單地讀 source_tab表的資料，相當於執行一個普通的SELECT語句，用一致性讀就可以了。ORACLE正是這麼做的，它通過MVCC技術實現的多版本資料來實現一致性讀，不需要給source_tab加任何鎖。我們知道InnoDB也實現了多版本資料，對普通的SELECT一致性讀，也不需要加任何鎖；但這裡InnoDB卻給source_tab加了共用鎖，並沒有使用多版本資料一致性讀技術！

MySQL為什麼要這麼做呢？其原因還是為了保證恢復和複製的正確性。因為不加鎖的話，如果在上述語句執行過程中，其他事務對source_tab做了更新操作，就可能導致資料恢復的結果錯誤。為了演示這一點，我們再重複一下前面的例子，不同的是在session_1執行事務前，先將系統變數 innodb_locks_unsafe_for_binlog的值設定為「on」（其預設值為off）

從上可見，設定系統變數innodb_locks_unsafe_for_binlog的值為「on」後，InnoDB不再對source_tab加鎖，結果也符合應用邏輯，但是如果分析BINLOG的內容：

SET TIMESTAMP=1169175130;

BEGIN;

# at 274

#070119 10:51:57 server id 1 end_log_pos 105 Query thread_id=1 exec_time=0 error_code=0

SET TIMESTAMP=1169175117;

update source_tab set name = '8' where name = '1';

# at 379

#070119 10:52:10 server id 1 end_log_pos 406 Xid = 5

COMMIT;

# at 406

#070119 10:52:14 server id 1 end_log_pos 474 Query thread_id=2 exec_time=0 error_code=0

SET TIMESTAMP=1169175134;

BEGIN;

# at 474

#070119 10:51:29 server id 1 end_log_pos 119 Query thread_id=2 exec_time=0 error_code=0

SET TIMESTAMP=1169175089;

insert into target_tab select d1,name from source_tab where name = '1';

# at 593

#070119 10:52:14 server id 1 end_log_pos 620 Xid = 7

COMMIT;

可以發現，在BINLOG中，更新操作的位置在INSERT...SELECT之前，如果使用這個BINLOG進行資料庫恢復，恢復的結果與實際的應用邏輯不符；如果進行復制，就會導致主從資料庫不一致！

因此，INSERT...SELECT...和 CREATE TABLE...SELECT...語句，可能會阻止對源表的並行更新，造成對源表鎖的等待。如果查詢比較複雜的話，會造成嚴重的效能問題，我們在應用中應儘量避免使用。實際上，MySQL將這種SQL叫作不確定（non-deterministic）的SQL，不推薦使用。

如果應用中一定要用這種SQL來實現業務邏輯，又不希望對源表的並行更新產生影響，可以採取以下兩種措施：

一是採取上面範例中的做法，將innodb_locks_unsafe_for_binlog的值設定為「on」，強制MySQL使用多版本資料一致性讀。但付出的代價是可能無法用binlog正確地恢復或複製資料，因此，不推薦使用這種方式。

二是通過使用「select * from source_tab ... Into outfile」和「load data infile ...」語句組合來間接實現，採用這種方式MySQL不會給source_tab加鎖。

8. InnoDB在不同隔離級別下的一致性讀及鎖的差異

前面講過，鎖和多版本資料是InnoDB實現一致性讀和ISO/ANSI SQL92隔離級別的手段，因此，在不同的隔離級別下，InnoDB處理SQL時採用的一致性讀策略和需要的鎖是不同的。同時，資料恢復和複製機制的特點，也對一些SQL的一致性讀策略和鎖策略有很大影響。將這些特性歸納成如表20-16所示的內容，以便讀者查閱。

1: 在隔離級別是RC情況下，間隙鎖是用不到的，官方檔案說明如下：

Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. For information about consistent reads, see Section 14.8.2.3, 「Consistent Nonlocking Reads」.

For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE statements, and DELETE statements, InnoDB locks only index records, not the gaps before them, and thus permits the free insertion of new records next to locked records. Gap locking is only used for foreign-key constraint checking and duplicate-key checking.

官方檔案說明地址為：https://dev.mysql.com/doc/refman/5.5/en/innodb-transaction-isolation-levels.html

2: 在可重複讀隔離級別下，如果索引是唯一的，且查詢也是唯一的，則也不用間隙鎖，否則就用間隙鎖，官方說明如下：

REPEATABLE READ

This is the default isolation level for InnoDB. Consistent reads within the same transaction read the snapshot established by the first read. This means that if you issue several plain (nonlocking) SELECT statements within the same transaction, theseSELECT statements are consistent also with respect to each other. See Section 14.8.2.3, 「Consistent Nonlocking Reads」.

For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition.

For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it.

For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key locks to block insertions by other sessions into the gaps covered by the range. For information about gap locks and next-key locks, see Section 14.8.1, 「InnoDB Locking」.

官方檔案說明地址為：https://dev.mysql.com/doc/refman/5.5/en/innodb-transaction-isolation-levels.html

9.什麼時候使用表鎖?

對於InnoDB表，在絕大部分情況下都應該使用行級鎖，因為事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個別特殊事務中，也可以考慮使用表級鎖。

第一種情況是：事務需要更新大部分或全部資料，表又比較大，如果使用預設的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖衝突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。

第二種情況是：事務涉及多個表，比較複雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少資料庫因事務回滾帶來的開銷。

當然，應用中這兩種事務不能太多，否則，就應該考慮使用MyISAM表了。

在InnoDB下，使用表鎖要注意以下兩點。

（1）使用LOCK TABLES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB儲存引擎層管理的，而是由其上一層: MySQL Server負責的，僅當autocommit=0、innodb_table_locks=1（預設設定）時，InnoDB層才能知道MySQL加的表鎖，MySQL Server也才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖；否則，InnoDB將無法自動檢測並處理這種死鎖。有關死鎖，下一小節還會繼續討論。

（2）在用 LOCK TABLES對InnoDB表加鎖時要注意，要將AUTOCOMMIT設為0，否則MySQL不會給表加鎖；事務結束前，不要用UNLOCK TABLES釋放表鎖，因為UNLOCK TABLES會隱含地提交事務；COMMIT或ROLLBACK並不能釋放用LOCK TABLES加的表級鎖，必須用UNLOCK TABLES釋放表鎖。正確的方式見如下語句.

例如，如果需要寫表t1並從表t讀，可以按如下做：

SET AUTOCOMMIT=0;

LOCK TABLES t1 WRITE, t2 READ, ...;

[do something with tables t1 and t2 here];

COMMIT;

UNLOCK TABLES;

10.關於死鎖

上文講過，MyISAM表鎖是deadlock free的，這是因為MyISAM總是一次獲得所需的全部鎖，要麼全部滿足，要麼等待，因此不會出現死鎖。但在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，這就決定了在InnoDB中發生死鎖是可能的。如表20-17所示的就是一個發生死鎖的例子。

在上面的例子中，兩個事務都需要獲得對方持有的排他鎖才能繼續完成事務，這種迴圈鎖等待就是典型的死鎖。

發生死鎖後，InnoDB一般都能自動檢測到，並使一個事務釋放鎖並回退，另一個事務獲得鎖，繼續完成事務。但在涉及外部鎖，或涉及表鎖的情況下，InnoDB並不能完全自動檢測到死鎖，這需要通過設定鎖等待超時引數innodb_lock_wait_timeout來解決。需要說明的是，這個引數並不是只用來解決死鎖問題，在並行存取比較高的情況下，如果大量事務因無法立即獲得所需的鎖而掛起，會佔用大量計算機資源，造成嚴重效能問題，甚至拖跨資料庫。我們通過設定合適的鎖等待超時閾值，可以避免這種情況發生。

通常來說，死鎖都是應用設計的問題，通過調整業務流程、資料庫物件設計、事務大小，以及存取資料庫的SQL語句，絕大部分死鎖都可以避免。

下面就通過範例來介紹幾種避免死鎖的常用方法。

（1）在應用中，如果不同的程式會並行存取多個表，應儘量約定以相同的順序來存取表，這樣可以大大降低產生死鎖的機會。在下面的例子中，由於兩個session存取兩個表的順序不同，發生死鎖的機會就非常高！但如果以相同的順序來存取，死鎖就可以避免。

（2）在程式以批次方式處理資料的時候，如果事先對資料排序，保證每個執行緒按固定的順序來處理記錄，也可以大大降低出現死鎖的可能。

（3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共用鎖，更新時再申請排他鎖，因為當使用者申請排他鎖時，其他事務可能又已經獲得了相同記錄的共用鎖，從而造成鎖衝突，甚至死鎖。具體演示可參見20.3.3小節中的例子。

（4）前面講過，在REPEATABLE-READ隔離級別下，如果兩個執行緒同時對相同條件記錄用SELECT...FOR UPDATE加排他鎖，在沒有符合該條件記錄情況下，兩個執行緒都會加鎖成功。程式發現記錄尚不存在，就試圖插入一條新記錄，如果兩個執行緒都這麼做，就會出現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可避免問題。

（5）當隔離級別為READ COMMITTED時，如果兩個執行緒都先執行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個執行緒能插入成功，另一個執行緒會出現鎖等待，當第1個執行緒提交後，第2個執行緒會因主鍵重出錯，但雖然這個執行緒出錯了，卻會獲得一個排他鎖！這時如果有第3個執行緒又來申請排他鎖，也會出現死鎖。

對於這種情況，可以直接做插入操作，然後再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖。

儘管通過上面介紹的設計和SQL優化等措施，可以大大減少死鎖，但死鎖很難完全避免。因此，在程式設計中總是捕獲並處理死鎖異常是一個很好的程式設計習慣。

如果出現死鎖，可以用SHOW INNODB STATUS命令來確定最後一個死鎖產生的原因。返回結果中包括死鎖相關事務的詳細資訊，如引發死鎖的SQL語句，事務已經獲得的鎖，正在等待什麼鎖，以及被回滾的事務等。據此可以分析死鎖產生的原因和改進措施。

下面是一段SHOW INNODB STATUS輸出的樣例：

mysql> show innodb status \G

InnoDB 小結

本章重點介紹了MySQL中MyISAM表級鎖和InnoDB行級鎖的實現特點，並討論了兩種儲存引擎經常遇到的鎖問題和解決辦法。

對於MyISAM的表鎖，主要討論了以下幾點：

（1）共用讀鎖（S）之間是相容的，但共用讀鎖（S）與排他寫鎖（X）之間，以及排他寫鎖（X）之間是互斥的，也就是說讀和寫是序列的。

（2）在一定條件下，MyISAM允許查詢和插入並行執行，我們可以利用這一點來解決應用中對同一表查詢和插入的鎖爭用問題。

（3）MyISAM預設的鎖排程機制是寫優先，這並不一定適合所有應用，使用者可以通過設定LOW_PRIORITY_UPDATES引數，或在INSERT、UPDATE、DELETE語句中指定LOW_PRIORITY選項來調節讀寫鎖的爭用。

（4）由於表鎖的鎖定粒度大，讀寫之間又是序列的，因此，如果更新操作較多，MyISAM表可能會出現嚴重的鎖等待，可以考慮採用InnoDB表來減少鎖衝突。

對於InnoDB表，本章主要討論了以下幾項內容。

InnoDB的行鎖是基於鎖引實現的，如果不通過索引存取資料，InnoDB會使用表鎖。

介紹了InnoDB間隙鎖（Next-key)機制，以及InnoDB使用間隙鎖的原因。

在不同的隔離級別下，InnoDB的鎖機制和一致性讀策略不同。

MySQL的恢復和複製對InnoDB鎖機制和一致性讀策略也有較大影響。

鎖衝突甚至死鎖很難完全避免。

在瞭解InnoDB鎖特性後，使用者可以通過設計和SQL調整等措施減少鎖衝突和死鎖，包括：

儘量使用較低的隔離級別；

精心設計索引，並儘量使用索引存取資料，使加鎖更精確，從而減少鎖衝突的機會。

選擇合理的事務大小，小事務發生鎖衝突的機率也更小。

給記錄集顯示加鎖時，最好一次性請求足夠級別的鎖。比如要修改資料的話，最好直接申請排他鎖，而不是先申請共用鎖，修改時再請求排他鎖，這樣容易產生死鎖。

不同的程式存取一組表時，應儘量約定以相同的順序存取各表，對一個表而言，儘可能以固定的順序存取表中的行。這樣可以大大減少死鎖的機會。

儘量用相等條件存取資料，這樣可以避免間隙鎖對並行插入的影響。

不要申請超過實際需要的鎖級別；除非必須，查詢時不要顯示加鎖。

對於一些特定的事務，可以使用表鎖來提高處理速度或減少死鎖的可能。