如何保證數(shù)據(jù)并發(fā)訪問的一致性、有效性是所有數(shù)據(jù)庫(kù)必須解決的一個(gè)問題，鎖沖突也是影響數(shù)據(jù)庫(kù)并發(fā)訪問性能的一個(gè)重要因素。從這個(gè)角度來說，鎖對(duì)數(shù)據(jù)庫(kù)而言顯得尤其重要，也更加復(fù)雜。

MySQL鎖概述

相對(duì)其他數(shù)據(jù)庫(kù)而言，MySQL的鎖機(jī)制比較簡(jiǎn)單，其最顯著的特點(diǎn)是不同的存儲(chǔ)引擎支持不同的鎖機(jī)制。 ?
? ? 比如

MyISAM和MEMORY存儲(chǔ)引擎采用的是表級(jí)鎖（table-level locking）。

InnoDB存儲(chǔ)引擎既支持行級(jí)鎖（row-level locking），也支持表級(jí)鎖，但默認(rèn)情況下是采用行級(jí)鎖。

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

表級(jí)鎖：開銷小，加鎖快；不會(huì)出現(xiàn)死鎖；鎖定粒度大，發(fā)生鎖沖突的概率最高,并發(fā)度最低。

行級(jí)鎖：開銷大，加鎖慢；會(huì)出現(xiàn)死鎖；鎖定粒度最小，發(fā)生鎖沖突的概率最低,并發(fā)度也最高。

頁面鎖：開銷和加鎖時(shí)間界于表鎖和行鎖之間；會(huì)出現(xiàn)死鎖；鎖定粒度界于表鎖和行鎖之間，并發(fā)度一般。

僅從鎖的角度來說：表級(jí)鎖更適合于以查詢?yōu)橹鳎挥猩倭堪此饕龡l件更新數(shù)據(jù)的應(yīng)用，如Web應(yīng)用；而行級(jí)鎖則更適合于有大量按索引條件并發(fā)更新少量不同數(shù)據(jù)，同時(shí)又有并發(fā)查詢的應(yīng)用，如一些在線事務(wù)處理（OLTP）系統(tǒng)。下面幾節(jié)我們重點(diǎn)介紹MySQL表鎖和 InnoDB行鎖的問題。

MyISAM表鎖

MyISAM存儲(chǔ)引擎只支持表鎖，這也是MySQL開始幾個(gè)版本中唯一支持的鎖類型。隨著應(yīng)用對(duì)事務(wù)完整性和并發(fā)性要求的不斷提高，MySQL才開始開發(fā)基于事務(wù)的存儲(chǔ)引擎，后來慢慢出現(xiàn)了支持頁鎖的BDB存儲(chǔ)引擎和支持行鎖的InnoDB存儲(chǔ)引擎（實(shí)際 InnoDB是單獨(dú)的一個(gè)公司，現(xiàn)在已經(jīng)被Oracle公司收購(gòu)）。但是MyISAM的表鎖依然是使用最為廣泛的鎖類型。本節(jié)將詳細(xì)介紹MyISAM表鎖的使用。

查詢表級(jí)鎖爭(zhēng)用情況

可以通過檢查table_locks_waited和table_locks_immediate狀態(tài)變量來分析系統(tǒng)上的表鎖定爭(zhēng)奪：

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的值比較高，則說明存在著較嚴(yán)重的表級(jí)鎖爭(zhēng)用情況。

MySQL表級(jí)鎖的鎖模式

MySQL的表級(jí)鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨(dú)占寫鎖（Table Write Lock）。

MyISAM表的讀操作，不會(huì)阻塞其他用戶對(duì)同一表的讀請(qǐng)求，但會(huì)阻塞對(duì)同一表的寫請(qǐng)求； ?
????MyISAM表的寫操作，則會(huì)阻塞其他用戶對(duì)同一表的讀和寫操作； ?
????MyISAM表的讀操作與寫操作之間，以及寫操作之間是串行的； ?
????當(dāng)一個(gè)線程獲得對(duì)一個(gè)表的寫鎖后，只有持有鎖的線程可以對(duì)表進(jìn)行更新操作。其他線程的讀、寫操作都會(huì)等待，直到鎖被釋放為止。

獲得表film_text的WRITE鎖定

mysql> lock table film_text write;

Query OK, 0 rows affected (0.00 sec)

當(dāng)前session對(duì)鎖定表的查詢、更新、插入操作都可以執(zhí)行：

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對(duì)鎖定表的查詢被阻塞，需要等待鎖被釋放：

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在執(zhí)行查詢語句（SELECT）前，會(huì)自動(dòng)給涉及的所有表加讀鎖，在執(zhí)行更新操作（UPDATE、DELETE、INSERT等）前，會(huì)自動(dòng)給涉及的表加寫鎖，這個(gè)過程并不需要用戶干預(yù)，因此，用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在示例中，顯式加鎖基本上都是為了方便而已，并非必須如此。

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

Select sum(total) from orders;

Select sum(subtotal) from order_detail;

這時(shí)，如果不先給兩個(gè)表加鎖，就可能產(chǎn)生錯(cuò)誤的結(jié)果，因?yàn)榈谝粭l語句執(zhí)行過程中，order_detail表可能已經(jīng)發(fā)生了改變。因此，正確的方法應(yīng)該是：

Lock tables orders read local, order_detail read local;

Select sum(total) from orders;

Select sum(subtotal) from order_detail;

Unlock tables;

要特別說明以下兩點(diǎn)內(nèi)容。

上面的例子在LOCK TABLES時(shí)加了“l(fā)ocal”選項(xiàng)，其作用就是在滿足MyISAM表并發(fā)插入條件的情況下，允許其他用戶在表尾并發(fā)插入記錄，有關(guān)MyISAM表的并發(fā)插入問題，后面還會(huì)進(jìn)一步介紹。

在用LOCK TABLES給表顯式加表鎖時(shí)，必須同時(shí)取得所有涉及到表的鎖，并且MySQL不支持鎖升級(jí)。也就是說，在執(zhí)行LOCK TABLES后，只能訪問顯式加鎖的這些表，不能訪問未加鎖的表；同時(shí)，如果加的是讀鎖，那么只能執(zhí)行查詢操作，而不能執(zhí)行更新操作。其實(shí)，在自動(dòng)加鎖的情況下也基本如此，MyISAM總是一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會(huì)出現(xiàn)死鎖（Deadlock Free）的原因。

一個(gè)session使用LOCK TABLE命令給表film_text加了讀鎖，這個(gè)session可以查詢鎖定表中的記錄，但更新或訪問其他表都會(huì)提示錯(cuò)誤；同時(shí)，另外一個(gè)session可以查詢表中的記錄，但更新就會(huì)出現(xiàn)鎖等待。

當(dāng)使用LOCK TABLES時(shí)，不僅需要一次鎖定用到的所有表，而且，同一個(gè)表在SQL語句中出現(xiàn)多少次，就要通過與SQL語句中相同的別名鎖定多少次，否則也會(huì)出錯(cuò)！

舉例說明如下。

（1）對(duì)actor表獲得讀鎖：

mysql> lock table actor read;

Query OK, 0 rows affected (0.00 sec)

（2）但是通過別名訪問會(huì)提示錯(cuò)誤：

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）需要對(duì)別名分別鎖定：

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

Query OK, 0 rows affected (0.00 sec)

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

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)

并發(fā)插入（Concurrent Inserts）

上文提到過MyISAM表的讀和寫是串行的，但這是就總體而言的。在一定條件下，MyISAM表也支持查詢和插入操作的并發(fā)進(jìn)行。

MyISAM存儲(chǔ)引擎有一個(gè)系統(tǒng)變量concurrent_insert，專門用以控制其并發(fā)插入的行為，其值分別可以為0、1或2。

當(dāng)concurrent_insert設(shè)置為0時(shí)，不允許并發(fā)插入。

當(dāng)concurrent_insert設(shè)置為1時(shí)，如果MyISAM表中沒有空洞（即表的中間沒有被刪除的行），MyISAM允許在一個(gè)進(jìn)程讀表的同時(shí)，另一個(gè)進(jìn)程從表尾插入記錄。這也是MySQL的默認(rèn)設(shè)置。

當(dāng)concurrent_insert設(shè)置為2時(shí)，無論MyISAM表中有沒有空洞，都允許在表尾并發(fā)插入記錄。

可以利用MyISAM存儲(chǔ)引擎的并發(fā)插入特性，來解決應(yīng)用中對(duì)同一表查詢和插入的鎖爭(zhēng)用。例如，將concurrent_insert系統(tǒng)變量設(shè)為2，總是允許并發(fā)插入；同時(shí)，通過定期在系統(tǒng)空閑時(shí)段執(zhí)行 OPTIMIZE TABLE語句來整理空間碎片，收回因刪除記錄而產(chǎn)生的中間空洞。有關(guān)OPTIMIZE TABLE語句的詳細(xì)介紹，可以參見第18章中“兩個(gè)簡(jiǎn)單實(shí)用的優(yōu)化方法”一節(jié)的內(nèi)容。

MyISAM的鎖調(diào)度

前面講過，MyISAM存儲(chǔ)引擎的讀鎖和寫鎖是互斥的，讀寫操作是串行的。那么，一個(gè)進(jìn)程請(qǐng)求某個(gè) MyISAM表的讀鎖，同時(shí)另一個(gè)進(jìn)程也請(qǐng)求同一表的寫鎖，MySQL如何處理呢？答案是寫進(jìn)程先獲得鎖。不僅如此，即使讀請(qǐng)求先到鎖等待隊(duì)列，寫請(qǐng)求后到，寫鎖也會(huì)插到讀鎖請(qǐng)求之前！這是因?yàn)镸ySQL認(rèn)為寫請(qǐng)求一般比讀請(qǐng)求要重要。這也正是MyISAM表不太適合于有大量更新操作和查詢操作應(yīng)用的原因，因?yàn)椋罅康母虏僮鲿?huì)造成查詢操作很難獲得讀鎖，從而可能永遠(yuǎn)阻塞。這種情況有時(shí)可能會(huì)變得非常糟糕！幸好我們可以通過一些設(shè)置來調(diào)節(jié)MyISAM 的調(diào)度行為。

通過指定啟動(dòng)參數(shù)low-priority-updates，使MyISAM引擎默認(rèn)給予讀請(qǐng)求以優(yōu)先的權(quán)利。

通過執(zhí)行命令SET LOW_PRIORITY_UPDATES=1，使該連接發(fā)出的更新請(qǐng)求優(yōu)先級(jí)降低。

通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優(yōu)先級(jí)。

雖然上面3種方法都是要么更新優(yōu)先，要么查詢優(yōu)先的方法，但還是可以用其來解決查詢相對(duì)重要的應(yīng)用（如用戶登錄系統(tǒng)）中，讀鎖等待嚴(yán)重的問題。

另外，MySQL也提供了一種折中的辦法來調(diào)節(jié)讀寫沖突，即給系統(tǒng)參數(shù)max_write_lock_count設(shè)置一個(gè)合適的值，當(dāng)一個(gè)表的讀鎖達(dá)到這個(gè)值后，MySQL就暫時(shí)將寫請(qǐng)求的優(yōu)先級(jí)降低，給讀進(jìn)程一定獲得鎖的機(jī)會(huì)。

上面已經(jīng)討論了寫優(yōu)先調(diào)度機(jī)制帶來的問題和解決辦法。這里還要強(qiáng)調(diào)一點(diǎn)：一些需要長(zhǎng)時(shí)間運(yùn)行的查詢操作，也會(huì)使寫進(jìn)程“餓死”！因此，應(yīng)用中應(yīng)盡量避免出現(xiàn)長(zhǎng)時(shí)間運(yùn)行的查詢操作，不要總想用一條SELECT語句來解決問題，因?yàn)檫@種看似巧妙的SQL語句，往往比較復(fù)雜，執(zhí)行時(shí)間較長(zhǎng)，在可能的情況下可以通過使用中間表等措施對(duì)SQL語句做一定的“分解”，使每一步查詢都能在較短時(shí)間完成，從而減少鎖沖突。如果復(fù)雜查詢不可避免，應(yīng)盡量安排在數(shù)據(jù)庫(kù)空閑時(shí)段執(zhí)行，比如一些定期統(tǒng)計(jì)可以安排在夜間執(zhí)行。

InnoDB鎖

InnoDB與MyISAM的最大不同有兩點(diǎn)：一是支持事務(wù)（TRANSACTION）；二是采用了行級(jí)鎖。行級(jí)鎖與表級(jí)鎖本來就有許多不同之處，另外，事務(wù)的引入也帶來了一些新問題。下面我們先介紹一點(diǎn)背景知識(shí)，然后詳細(xì)討論InnoDB的鎖問題。

1.事務(wù)（Transaction）及其ACID屬性

事務(wù)是由一組SQL語句組成的邏輯處理單元，事務(wù)具有以下4個(gè)屬性，通常簡(jiǎn)稱為事務(wù)的ACID屬性。

（Atomicity）原子性：事務(wù)是一個(gè)原子操作單元，其對(duì)數(shù)據(jù)的修改，要么全都執(zhí)行，要么全都不執(zhí)行。

（Consistent）一致性：在事務(wù)開始和完成時(shí)，數(shù)據(jù)都必須保持一致狀態(tài)。這意味著所有相關(guān)的數(shù)據(jù)規(guī)則都必須應(yīng)用于事務(wù)的修改，以保持?jǐn)?shù)據(jù)的完整性；事務(wù)結(jié)束時(shí)，所有的內(nèi)部數(shù)據(jù)結(jié)構(gòu)（如B樹索引或雙向鏈表）也都必須是正確的。

（Isolation）隔離性：數(shù)據(jù)庫(kù)系統(tǒng)提供一定的隔離機(jī)制，保證事務(wù)在不受外部并發(fā)操作影響的“獨(dú)立”環(huán)境執(zhí)行。這意味著事務(wù)處理過程中的中間狀態(tài)對(duì)外部是不可見的，反之亦然。

（Durable）持久性：事務(wù)完成之后，它對(duì)于數(shù)據(jù)的修改是永久性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。

銀行轉(zhuǎn)帳就是事務(wù)的一個(gè)典型例子。

2.并發(fā)事務(wù)處理帶來的問題

相對(duì)于串行處理來說，并發(fā)事務(wù)處理能大大增加數(shù)據(jù)庫(kù)資源的利用率，提高數(shù)據(jù)庫(kù)系統(tǒng)的事務(wù)吞吐量，從而可以支持更多的用戶。但并發(fā)事務(wù)處理也會(huì)帶來一些問題，主要包括以下幾種情況。

更新丟失（Lost Update）：當(dāng)兩個(gè)或多個(gè)事務(wù)選擇同一行，然后基于最初選定的值更新該行時(shí)，由于每個(gè)事務(wù)都不知道其他事務(wù)的存在，就會(huì)發(fā)生丟失更新問題－－最后的更新覆蓋了由其他事務(wù)所做的更新。例如，兩個(gè)編輯人員制作了同一文檔的電子副本。每個(gè)編輯人員獨(dú)立地更改其副本，然后保存更改后的副本，這樣就覆蓋了原始文檔。最后保存其更改副本的編輯人員覆蓋另一個(gè)編輯人員所做的更改。如果在一個(gè)編輯人員完成并提交事務(wù)之前，另一個(gè)編輯人員不能訪問同一文件，則可避免此問題。

臟讀（Dirty Reads）：一個(gè)事務(wù)正在對(duì)一條記錄做修改，在這個(gè)事務(wù)完成并提交前，這條記錄的數(shù)據(jù)就處于不一致狀態(tài)；這時(shí)，另一個(gè)事務(wù)也來讀取同一條記錄，如果不加控制，第二個(gè)事務(wù)讀取了這些“臟”數(shù)據(jù)，并據(jù)此做進(jìn)一步的處理，就會(huì)產(chǎn)生未提交的數(shù)據(jù)依賴關(guān)系。這種現(xiàn)象被形象地叫做”臟讀”。

不可重復(fù)讀（Non-Repeatable Reads）：一個(gè)事務(wù)在讀取某些數(shù)據(jù)后的某個(gè)時(shí)間，再次讀取以前讀過的數(shù)據(jù)，卻發(fā)現(xiàn)其讀出的數(shù)據(jù)已經(jīng)發(fā)生了改變、或某些記錄已經(jīng)被刪除了！這種現(xiàn)象就叫做“不可重復(fù)讀”。

幻讀（Phantom Reads）：一個(gè)事務(wù)按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù)，卻發(fā)現(xiàn)其他事務(wù)插入了滿足其查詢條件的新數(shù)據(jù)，這種現(xiàn)象就稱為“幻讀”。

3.事務(wù)隔離級(jí)別

在上面講到的并發(fā)事務(wù)處理帶來的問題中，“更新丟失”通常是應(yīng)該完全避免的。但防止更新丟失，并不能單靠數(shù)據(jù)庫(kù)事務(wù)控制器來解決，需要應(yīng)用程序?qū)σ碌臄?shù)據(jù)加必要的鎖來解決，因此，防止更新丟失應(yīng)該是應(yīng)用的責(zé)任。

“臟讀”、“不可重復(fù)讀”和“幻讀”，其實(shí)都是數(shù)據(jù)庫(kù)讀一致性問題，必須由數(shù)據(jù)庫(kù)提供一定的事務(wù)隔離機(jī)制來解決。數(shù)據(jù)庫(kù)實(shí)現(xiàn)事務(wù)隔離的方式，基本上可分為以下兩種。

一種是在讀取數(shù)據(jù)前，對(duì)其加鎖，阻止其他事務(wù)對(duì)數(shù)據(jù)進(jìn)行修改。

另一種是不用加任何鎖，通過一定機(jī)制生成一個(gè)數(shù)據(jù)請(qǐng)求時(shí)間點(diǎn)的一致性數(shù)據(jù)快照（Snapshot)，并用這個(gè)快照來提供一定級(jí)別（語句級(jí)或事務(wù)級(jí)）的一致性讀取。從用戶的角度來看，好像是數(shù)據(jù)庫(kù)可以提供同一數(shù)據(jù)的多個(gè)版本，因此，這種技術(shù)叫做數(shù)據(jù)多版本并發(fā)控制（MultiVersion Concurrency Control，簡(jiǎn)稱MVCC或MCC），也經(jīng)常稱為多版本數(shù)據(jù)庫(kù)。

一致性讀，又稱為快照讀。使用的是MVCC機(jī)制讀取undo中的已經(jīng)提交的數(shù)據(jù)。所以它的讀取是非阻塞的。

一致性讀肯定是讀取在某個(gè)時(shí)間點(diǎn)已經(jīng)提交了的數(shù)據(jù)，有個(gè)特例：本事務(wù)中修改的數(shù)據(jù)，即使未提交的數(shù)據(jù)也可以在本事務(wù)的后面部分讀取到。一致性讀是指普通的select語句，不帶 for update, in share mode 等等子句。使用的是undo中的提交的數(shù)據(jù)，不需要使用鎖(MDL除外)。而當(dāng)前讀，是指update, delete, select for update, select in share mode等等語句進(jìn)行的讀，它們讀取的是數(shù)據(jù)庫(kù)中的最新的數(shù)據(jù)，并且會(huì)鎖住讀取的行和gap(RR隔離時(shí))。如果不能獲得鎖，則會(huì)一直等待，直到獲得或者超時(shí)。

數(shù)據(jù)庫(kù)的事務(wù)隔離越嚴(yán)格，并發(fā)副作用越小，但付出的代價(jià)也就越大，因?yàn)槭聞?wù)隔離實(shí)質(zhì)上就是使事務(wù)在一定程度上 “串行化”進(jìn)行，這顯然與“并發(fā)”是矛盾的。同時(shí)，不同的應(yīng)用對(duì)讀一致性和事務(wù)隔離程度的要求也是不同的，比如許多應(yīng)用對(duì)“不可重復(fù)讀”和“幻讀”并不敏感，可能更關(guān)心數(shù)據(jù)并發(fā)訪問的能力。

為了解決“隔離”與“并發(fā)”的矛盾，ISO/ANSI SQL92定義了4個(gè)事務(wù)隔離級(jí)別，每個(gè)級(jí)別的隔離程度不同，允許出現(xiàn)的副作用也不同，應(yīng)用可以根據(jù)自己的業(yè)務(wù)邏輯要求，通過選擇不同的隔離級(jí)別來平衡 “隔離”與“并發(fā)”的矛盾。表20-5很好地概括了這4個(gè)隔離級(jí)別的特性。

各具體數(shù)據(jù)庫(kù)并不一定完全實(shí)現(xiàn)了上述4個(gè)隔離級(jí)別Oracle只提供Read committed和Serializable兩個(gè)標(biāo)準(zhǔn)隔離級(jí)別，另外還提供自己定義的Read only隔離級(jí)別；SQL Server除支持上述ISO/ANSI SQL92定義的4個(gè)隔離級(jí)別外，還支持一個(gè)叫做“快照”的隔離級(jí)別，但嚴(yán)格來說它是一個(gè)用MVCC實(shí)現(xiàn)的Serializable隔離級(jí)別。

MySQL 支持全部4個(gè)隔離級(jí)別，但在具體實(shí)現(xiàn)時(shí)，有一些特點(diǎn)，比如在一些隔離級(jí)別下是采用MVCC一致性讀，但某些情況下又不是，這些內(nèi)容在后面的章節(jié)中將會(huì)做進(jìn)一步介紹。

4.獲取InnoDB行鎖爭(zhēng)用情況

可以通過檢查InnoDB_row_lock狀態(tài)變量來分析系統(tǒng)上的行鎖的爭(zhēng)奪情況。

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)

如果發(fā)現(xiàn)鎖爭(zhēng)用比較嚴(yán)重，如InnoDB_row_lock_waits 和 InnoDB_row_lock_time_avg的值比較高，還可以通過設(shè)置InnoDB Monitors來進(jìn)一步觀察發(fā)生鎖沖突的表、數(shù)據(jù)行等，并分析鎖爭(zhēng)用的原因。

具體方法如下：

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

Query OK, 0 rows affected (0.14 sec)

然后就可以用下面的語句來進(jìn)行查看：

mysql> Show innodb statusG;

監(jiān)視器可以通過發(fā)出下列語句來停止查看：

mysql> DROP TABLE innodb_monitor;

Query OK, 0 rows affected (0.05 sec)

設(shè)置監(jiān)視器后，在SHOW INNODB STATUS的顯示內(nèi)容中，會(huì)有詳細(xì)的當(dāng)前鎖等待的信息，包括表名、鎖類型、鎖定記錄的情況等，便于進(jìn)行進(jìn)一步的分析和問題的確定。打開監(jiān)視器以后，默認(rèn)情況下每15秒會(huì)向日志中記錄監(jiān)控的內(nèi)容，如果長(zhǎng)時(shí)間打開會(huì)導(dǎo)致.err文件變得非常的巨大，所以用戶在確認(rèn)問題原因之后，要記得刪除監(jiān)控表以關(guān)閉監(jiān)視器，或者通過使用“–console”選項(xiàng)來啟動(dòng)服務(wù)器以關(guān)閉寫日志文件。

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

InnoDB實(shí)現(xiàn)了以下兩種類型的行鎖。

共享鎖（S）：允許一個(gè)事務(wù)去讀一行，阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖。

排他鎖（X）：允許獲得排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同數(shù)據(jù)集的共享讀鎖和排他寫鎖。

另外，為了允許行鎖和表鎖共存，實(shí)現(xiàn)多粒度鎖機(jī)制，InnoDB還有兩種內(nèi)部使用的意向鎖（Intention Locks），

這兩種意向鎖都是表鎖。

意向共享鎖（IS）：事務(wù)打算給數(shù)據(jù)行加行共享鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖。

意向排他鎖（IX）：事務(wù)打算給數(shù)據(jù)行加行排他鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。

如果一個(gè)事務(wù)請(qǐng)求的鎖模式與當(dāng)前的鎖兼容，InnoDB就將請(qǐng)求的鎖授予該事務(wù)；反之，如果兩者不兼容，該事務(wù)就要等待鎖釋放。

意向鎖是InnoDB自動(dòng)加的，不需用戶干預(yù)。

總結(jié)如下：

1.? ?對(duì)于UPDATE、DELETE和INSERT語句，InnoDB會(huì)自動(dòng)給涉及數(shù)據(jù)集加排他鎖（X）；

2.? 對(duì)于普通SELECT語句，InnoDB不會(huì)加任何鎖；

3.? 事務(wù)可以通過以下語句顯示給記錄集加共享鎖或排他鎖。

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

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

用SELECT … IN SHARE MODE獲得共享鎖，主要用在需要數(shù)據(jù)依存關(guān)系時(shí)來確認(rèn)某行記錄是否存在，并確保沒有人對(duì)這個(gè)記錄進(jìn)行UPDATE或者DELETE操作。

但是如果當(dāng)前事務(wù)也需要對(duì)該記錄進(jìn)行更新操作，則很有可能造成死鎖，對(duì)于鎖定行記錄后需要進(jìn)行更新操作的應(yīng)用，應(yīng)該使用SELECT… FOR UPDATE方式獲得排他鎖。

6. InnoDB行鎖實(shí)現(xiàn)方式

InnoDB行鎖是通過給索引上的索引項(xiàng)加鎖來實(shí)現(xiàn)的，這一點(diǎn)MySQL與Oracle不同，后者是通過在數(shù)據(jù)塊中對(duì)相應(yīng)數(shù)據(jù)行加鎖來實(shí)現(xiàn)的。

InnoDB這種行鎖實(shí)現(xiàn)特點(diǎn)意味著：只有通過索引條件檢索數(shù)據(jù)，InnoDB才使用行級(jí)鎖，否則，InnoDB將使用表鎖！

在實(shí)際應(yīng)用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導(dǎo)致大量的鎖沖突，從而影響并發(fā)性能。

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

（2）由于MySQL的行鎖是針對(duì)索引加的鎖，不是針對(duì)記錄加的鎖，所以雖然是訪問不同行的記錄，

但是如果是使用相同的索引鍵，是會(huì)出現(xiàn)鎖沖突的。應(yīng)用設(shè)計(jì)的時(shí)候要注意這一點(diǎn)。

（3）當(dāng)表有多個(gè)索引的時(shí)候，不同的事務(wù)可以使用不同的索引鎖定不同的行，

另外，不論是使用主鍵索引、唯一索引或普通索引，InnoDB都會(huì)使用行鎖來對(duì)數(shù)據(jù)加鎖。

（4）即便在條件中使用了索引字段，但是否使用索引來檢索數(shù)據(jù)是由MySQL通過判斷不同執(zhí)行計(jì)劃的代價(jià)來決定的，如果MySQL認(rèn)為全表掃描效率更高，比如對(duì)一些很小的表，它就不會(huì)使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖沖突時(shí)，別忘了檢查SQL的執(zhí)行計(jì)劃，以確認(rèn)是否真正使用了索引。關(guān)于MySQL在什么情況下不使用索引的詳細(xì)討論，參見本章“索引問題”一節(jié)的介紹。

7. 間隙鎖（Next-Key鎖）

當(dāng)我們用范圍條件而不是相等條件檢索數(shù)據(jù)，并請(qǐng)求共享或排他鎖時(shí)，InnoDB會(huì)給符合條件的已有數(shù)據(jù)記錄的索引項(xiàng)加鎖；對(duì)于鍵值在條件范圍內(nèi)但并不存在的記錄，叫做“間隙（GAP）”，InnoDB也會(huì)對(duì)這個(gè)“間隙”加鎖，這種鎖機(jī)制就是所謂的間隙鎖（Next-Key鎖）。假如emp表中只有101條記錄，其empid的值分別是 1,2,…,100,101 下面的SQL：

Select * from ?emp where empid > 100 for update;

是一個(gè)范圍條件的檢索，InnoDB不僅會(huì)對(duì)符合條件的empid值為101的記錄加鎖，也會(huì)對(duì)empid大于101（這些記錄并不存在）的“間隙”加鎖。InnoDB使用間隙鎖的目的，一方面是為了防止幻讀，以滿足相關(guān)隔離級(jí)別的要求，對(duì)于上面的例子，要是不使用間隙鎖，如果其他事務(wù)插入了empid大于100的任何記錄，那么本事務(wù)如果再次執(zhí)行上述語句，就會(huì)發(fā)生幻讀；另外一方面，是為了滿足其恢復(fù)和復(fù)制的需要。有關(guān)其恢復(fù)和復(fù)制對(duì)鎖機(jī)制的影響，以及不同隔離級(jí)別下InnoDB使用間隙鎖的情況，在后續(xù)的章節(jié)中會(huì)做進(jìn)一步介紹。

很顯然，在使用范圍條件檢索并鎖定記錄時(shí)，InnoDB這種加鎖機(jī)制會(huì)阻塞符合條件范圍內(nèi)鍵值的并發(fā)插入，這往往會(huì)造成嚴(yán)重的鎖等待。因此，在實(shí)際應(yīng)用開發(fā)中，尤其是并發(fā)插入比較多的應(yīng)用，我們要盡量?jī)?yōu)化業(yè)務(wù)邏輯，盡量使用相等條件來訪問更新數(shù)據(jù)，避免使用范圍條件。

特別說明的是，InnoDB除了通過范圍條件加鎖時(shí)使用間隙鎖外，如果使用相等條件請(qǐng)求給一個(gè)不存在的記錄加鎖，InnoDB也會(huì)使用間隙鎖！

恢復(fù)和復(fù)制的需要，對(duì)InnoDB鎖機(jī)制的影響

MySQL通過BINLOG記錄執(zhí)行成功的INSERT、UPDATE、DELETE等更新數(shù)據(jù)的SQL語句，并由此實(shí)現(xiàn)MySQL數(shù)據(jù)庫(kù)的恢復(fù)和主從復(fù)制。MySQL的恢復(fù)機(jī)制（復(fù)制其實(shí)就是在Slave Mysql不斷做基于BINLOG的恢復(fù)）有以下特點(diǎn)。

一是MySQL的恢復(fù)是SQL語句級(jí)的，也就是重新執(zhí)行BINLOG中的SQL語句。這與Oracle數(shù)據(jù)庫(kù)不同，Oracle是基于數(shù)據(jù)庫(kù)文件塊的。

二是MySQL的BINLOG是按照事務(wù)提交的先后順序記錄的，恢復(fù)也是按這個(gè)順序進(jìn)行的。這點(diǎn)也與Oralce不同，Oracle是按照系統(tǒng)更新號(hào)（System Change Number，SCN）來恢復(fù)數(shù)據(jù)的，每個(gè)事務(wù)開始時(shí)，Oracle都會(huì)分配一個(gè)全局唯一的SCN，SCN的順序與事務(wù)開始的時(shí)間順序是一致的。

從上面兩點(diǎn)可知，MySQL的恢復(fù)機(jī)制要求：在一個(gè)事務(wù)未提交前，其他并發(fā)事務(wù)不能插入滿足其鎖定條件的任何記錄，也就是不允許出現(xiàn)幻讀，這已經(jīng)超過了ISO/ANSI SQL92“可重復(fù)讀”隔離級(jí)別的要求，實(shí)際上是要求事務(wù)要串行化。

另外，對(duì)于“insert? into target_tab select * from source_tab where …”和“create? table new_tab …select … From? source_tab where …(CTAS)”這種SQL語句，用戶并沒有對(duì)source_tab做任何更新操作，但MySQL對(duì)這種SQL語句做了特別處理。

（這里InnoDB卻給source_tab加了共享鎖，并沒有使用多版本數(shù)據(jù)一致性讀技術(shù)！） ?

在上面的例子中，只是簡(jiǎn)單地讀 source_tab表的數(shù)據(jù)，相當(dāng)于執(zhí)行一個(gè)普通的SELECT語句，用一致性讀就可以了。ORACLE正是這么做的，它通過MVCC技術(shù)實(shí)現(xiàn)的多版本數(shù)據(jù)來實(shí)現(xiàn)一致性讀，不需要給source_tab加任何鎖。我們知道InnoDB也實(shí)現(xiàn)了多版本數(shù)據(jù)，對(duì)普通的SELECT一致性讀，也不需要加任何鎖；但這里InnoDB卻給source_tab加了共享鎖，并沒有使用多版本數(shù)據(jù)一致性讀技術(shù)！

MySQL為什么要這么做呢？其原因還是為了保證恢復(fù)和復(fù)制的正確性。因?yàn)椴患渔i的話，如果在上述語句執(zhí)行過程中，其他事務(wù)對(duì)source_tab做了更新操作，就可能導(dǎo)致數(shù)據(jù)恢復(fù)的結(jié)果錯(cuò)誤。為了演示這一點(diǎn)，我們?cè)僦貜?fù)一下前面的例子，不同的是在session_1執(zhí)行事務(wù)前，先將系統(tǒng)變量 innodb_locks_unsafe_for_binlog的值設(shè)置為“on”（其默認(rèn)值為off）

從上可見，設(shè)置系統(tǒng)變量innodb_locks_unsafe_for_binlog的值為“on”后，InnoDB不再對(duì)source_tab加鎖，結(jié)果也符合應(yīng)用邏輯，但是如果分析BINLOG的內(nèi)容：

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;

可以發(fā)現(xiàn)，在BINLOG中，更新操作的位置在INSERT…SELECT之前，如果使用這個(gè)BINLOG進(jìn)行數(shù)據(jù)庫(kù)恢復(fù)，恢復(fù)的結(jié)果與實(shí)際的應(yīng)用邏輯不符；如果進(jìn)行復(fù)制，就會(huì)導(dǎo)致主從數(shù)據(jù)庫(kù)不一致！

因此，INSERT…SELECT…和 CREATE TABLE…SELECT…語句，可能會(huì)阻止對(duì)源表的并發(fā)更新，造成對(duì)源表鎖的等待。如果查詢比較復(fù)雜的話，會(huì)造成嚴(yán)重的性能問題，我們?cè)趹?yīng)用中應(yīng)盡量避免使用。實(shí)際上，MySQL將這種SQL叫作不確定（non-deterministic）的SQL，不推薦使用。

如果應(yīng)用中一定要用這種SQL來實(shí)現(xiàn)業(yè)務(wù)邏輯，又不希望對(duì)源表的并發(fā)更新產(chǎn)生影響，可以采取以下兩種措施：

一是采取上面示例中的做法，將innodb_locks_unsafe_for_binlog的值設(shè)置為“on”，強(qiáng)制MySQL使用多版本數(shù)據(jù)一致性讀。但付出的代價(jià)是可能無法用binlog正確地恢復(fù)或復(fù)制數(shù)據(jù)，因此，不推薦使用這種方式。

二是通過使用“select * from source_tab … Into outfile”和“l(fā)oad data infile …”語句組合來間接實(shí)現(xiàn)，采用這種方式MySQL不會(huì)給source_tab加鎖。

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

前面講過，鎖和多版本數(shù)據(jù)是InnoDB實(shí)現(xiàn)一致性讀和ISO/ANSI SQL92隔離級(jí)別的手段，因此，在不同的隔離級(jí)別下，InnoDB處理SQL時(shí)采用的一致性讀策略和需要的鎖是不同的。同時(shí)，數(shù)據(jù)恢復(fù)和復(fù)制機(jī)制的特點(diǎn)，也對(duì)一些SQL的一致性讀策略和鎖策略有很大影響。將這些特性歸納成如表20-16所示的內(nèi)容，以便讀者查閱。

1: 在隔離級(jí)別是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: 在可重復(fù)讀隔離級(jí)別下，如果索引是唯一的，且查找也是唯一的，則也不用間隙鎖，否則就用間隙鎖，官方說明如下：

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.什么時(shí)候使用表鎖?

對(duì)于InnoDB表，在絕大部分情況下都應(yīng)該使用行級(jí)鎖，因?yàn)槭聞?wù)和行鎖往往是我們之所以選擇InnoDB表的理由。但在個(gè)別特殊事務(wù)中，也可以考慮使用表級(jí)鎖。

第一種情況是：事務(wù)需要更新大部分或全部數(shù)據(jù)，表又比較大，如果使用默認(rèn)的行鎖，不僅這個(gè)事務(wù)執(zhí)行效率低，而且可能造成其他事務(wù)長(zhǎng)時(shí)間鎖等待和鎖沖突，這種情況下可以考慮使用表鎖來提高該事務(wù)的執(zhí)行速度。

第二種情況是：事務(wù)涉及多個(gè)表，比較復(fù)雜，很可能引起死鎖，造成大量事務(wù)回滾。這種情況也可以考慮一次性鎖定事務(wù)涉及的表，從而避免死鎖、減少數(shù)據(jù)庫(kù)因事務(wù)回滾帶來的開銷。

當(dāng)然，應(yīng)用中這兩種事務(wù)不能太多，否則，就應(yīng)該考慮使用MyISAM表了。

在InnoDB下，使用表鎖要注意以下兩點(diǎn)。

（1）使用LOCK TABLES雖然可以給InnoDB加表級(jí)鎖，但必須說明的是，表鎖不是由InnoDB存儲(chǔ)引擎層管理的，而是由其上一層: MySQL Server負(fù)責(zé)的，僅當(dāng)autocommit=0、innodb_table_locks=1（默認(rèn)設(shè)置）時(shí)，InnoDB層才能知道MySQL加的表鎖，MySQL Server也才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動(dòng)識(shí)別涉及表級(jí)鎖的死鎖；否則，InnoDB將無法自動(dòng)檢測(cè)并處理這種死鎖。有關(guān)死鎖，下一小節(jié)還會(huì)繼續(xù)討論。

（2）在用 LOCK TABLES對(duì)InnoDB表加鎖時(shí)要注意，要將AUTOCOMMIT設(shè)為0，否則MySQL不會(huì)給表加鎖；事務(wù)結(jié)束前，不要用UNLOCK TABLES釋放表鎖，因?yàn)閁NLOCK TABLES會(huì)隱含地提交事務(wù)；COMMIT或ROLLBACK并不能釋放用LOCK TABLES加的表級(jí)鎖，必須用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.關(guān)于死鎖

上文講過，MyISAM表鎖是deadlock free的，這是因?yàn)镸yISAM總是一次獲得所需的全部鎖，要么全部滿足，要么等待，因此不會(huì)出現(xiàn)死鎖。但在InnoDB中，除單個(gè)SQL組成的事務(wù)外，鎖是逐步獲得的，這就決定了在InnoDB中發(fā)生死鎖是可能的。如表20-17所示的就是一個(gè)發(fā)生死鎖的例子。

在上面的例子中，兩個(gè)事務(wù)都需要獲得對(duì)方持有的排他鎖才能繼續(xù)完成事務(wù)，這種循環(huán)鎖等待就是典型的死鎖。

發(fā)生死鎖后，InnoDB一般都能自動(dòng)檢測(cè)到，并使一個(gè)事務(wù)釋放鎖并回退，另一個(gè)事務(wù)獲得鎖，繼續(xù)完成事務(wù)。但在涉及外部鎖，或涉及表鎖的情況下，InnoDB并不能完全自動(dòng)檢測(cè)到死鎖，這需要通過設(shè)置鎖等待超時(shí)參數(shù)innodb_lock_wait_timeout來解決。需要說明的是，這個(gè)參數(shù)并不是只用來解決死鎖問題，在并發(fā)訪問比較高的情況下，如果大量事務(wù)因無法立即獲得所需的鎖而掛起，會(huì)占用大量計(jì)算機(jī)資源，造成嚴(yán)重性能問題，甚至拖跨數(shù)據(jù)庫(kù)。我們通過設(shè)置合適的鎖等待超時(shí)閾值，可以避免這種情況發(fā)生。

通常來說，死鎖都是應(yīng)用設(shè)計(jì)的問題，通過調(diào)整業(yè)務(wù)流程、數(shù)據(jù)庫(kù)對(duì)象設(shè)計(jì)、事務(wù)大小，以及訪問數(shù)據(jù)庫(kù)的SQL語句，絕大部分死鎖都可以避免。

下面就通過實(shí)例來介紹幾種避免死鎖的常用方法。

（1）在應(yīng)用中，如果不同的程序會(huì)并發(fā)存取多個(gè)表，應(yīng)盡量約定以相同的順序來訪問表，這樣可以大大降低產(chǎn)生死鎖的機(jī)會(huì)。在下面的例子中，由于兩個(gè)session訪問兩個(gè)表的順序不同，發(fā)生死鎖的機(jī)會(huì)就非常高！但如果以相同的順序來訪問，死鎖就可以避免。

（2）在程序以批量方式處理數(shù)據(jù)的時(shí)候，如果事先對(duì)數(shù)據(jù)排序，保證每個(gè)線程按固定的順序來處理記錄，也可以大大降低出現(xiàn)死鎖的可能。

（3）在事務(wù)中，如果要更新記錄，應(yīng)該直接申請(qǐng)足夠級(jí)別的鎖，即排他鎖，而不應(yīng)先申請(qǐng)共享鎖，更新時(shí)再申請(qǐng)排他鎖，因?yàn)楫?dāng)用戶申請(qǐng)排他鎖時(shí)，其他事務(wù)可能又已經(jīng)獲得了相同記錄的共享鎖，從而造成鎖沖突，甚至死鎖。具體演示可參見20.3.3小節(jié)中的例子。

（4）前面講過，在REPEATABLE-READ隔離級(jí)別下，如果兩個(gè)線程同時(shí)對(duì)相同條件記錄用SELECT…FOR UPDATE加排他鎖，在沒有符合該條件記錄情況下，兩個(gè)線程都會(huì)加鎖成功。程序發(fā)現(xiàn)記錄尚不存在，就試圖插入一條新記錄，如果兩個(gè)線程都這么做，就會(huì)出現(xiàn)死鎖。這種情況下，將隔離級(jí)別改成READ COMMITTED，就可避免問題。

（5）當(dāng)隔離級(jí)別為READ COMMITTED時(shí)，如果兩個(gè)線程都先執(zhí)行SELECT…FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時(shí)，只有一個(gè)線程能插入成功，另一個(gè)線程會(huì)出現(xiàn)鎖等待，當(dāng)?shù)?個(gè)線程提交后，第2個(gè)線程會(huì)因主鍵重出錯(cuò)，但雖然這個(gè)線程出錯(cuò)了，卻會(huì)獲得一個(gè)排他鎖！這時(shí)如果有第3個(gè)線程又來申請(qǐng)排他鎖，也會(huì)出現(xiàn)死鎖。

對(duì)于這種情況，可以直接做插入操作，然后再捕獲主鍵重異常，或者在遇到主鍵重錯(cuò)誤時(shí)，總是執(zhí)行ROLLBACK釋放獲得的排他鎖。

盡管通過上面介紹的設(shè)計(jì)和SQL優(yōu)化等措施，可以大大減少死鎖，但死鎖很難完全避免。因此，在程序設(shè)計(jì)中總是捕獲并處理死鎖異常是一個(gè)很好的編程習(xí)慣。

如果出現(xiàn)死鎖，可以用SHOW INNODB STATUS命令來確定最后一個(gè)死鎖產(chǎn)生的原因。返回結(jié)果中包括死鎖相關(guān)事務(wù)的詳細(xì)信息，如引發(fā)死鎖的SQL語句，事務(wù)已經(jīng)獲得的鎖，正在等待什么鎖，以及被回滾的事務(wù)等。據(jù)此可以分析死鎖產(chǎn)生的原因和改進(jìn)措施。

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

mysql> show innodb status G

InnoDB 小結(jié)

本章重點(diǎn)介紹了MySQL中MyISAM表級(jí)鎖和InnoDB行級(jí)鎖的實(shí)現(xiàn)特點(diǎn)，并討論了兩種存儲(chǔ)引擎經(jīng)常遇到的鎖問題和解決辦法。

對(duì)于MyISAM的表鎖，主要討論了以下幾點(diǎn)：

（1）共享讀鎖（S）之間是兼容的，但共享讀鎖（S）與排他寫鎖（X）之間，以及排他寫鎖（X）之間是互斥的，也就是說讀和寫是串行的。

（2）在一定條件下，MyISAM允許查詢和插入并發(fā)執(zhí)行，我們可以利用這一點(diǎn)來解決應(yīng)用中對(duì)同一表查詢和插入的鎖爭(zhēng)用問題。

（3）MyISAM默認(rèn)的鎖調(diào)度機(jī)制是寫優(yōu)先，這并不一定適合所有應(yīng)用，用戶可以通過設(shè)置LOW_PRIORITY_UPDATES參數(shù)，或在INSERT、UPDATE、DELETE語句中指定LOW_PRIORITY選項(xiàng)來調(diào)節(jié)讀寫鎖的爭(zhēng)用。

（4）由于表鎖的鎖定粒度大，讀寫之間又是串行的，因此，如果更新操作較多，MyISAM表可能會(huì)出現(xiàn)嚴(yán)重的鎖等待，可以考慮采用InnoDB表來減少鎖沖突。

對(duì)于InnoDB表，本章主要討論了以下幾項(xiàng)內(nèi)容。

InnoDB的行鎖是基于鎖引實(shí)現(xiàn)的，如果不通過索引訪問數(shù)據(jù)，InnoDB會(huì)使用表鎖。

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

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

MySQL的恢復(fù)和復(fù)制對(duì)InnoDB鎖機(jī)制和一致性讀策略也有較大影響。

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

在了解InnoDB鎖特性后，用戶可以通過設(shè)計(jì)和SQL調(diào)整等措施減少鎖沖突和死鎖，包括：

盡量使用較低的隔離級(jí)別；

精心設(shè)計(jì)索引，并盡量使用索引訪問數(shù)據(jù)，使加鎖更精確，從而減少鎖沖突的機(jī)會(huì)。

選擇合理的事務(wù)大小，小事務(wù)發(fā)生鎖沖突的幾率也更小。

給記錄集顯示加鎖時(shí)，最好一次性請(qǐng)求足夠級(jí)別的鎖。比如要修改數(shù)據(jù)的話，最好直接申請(qǐng)排他鎖，而不是先申請(qǐng)共享鎖，修改時(shí)再請(qǐng)求排他鎖，這樣容易產(chǎn)生死鎖。

不同的程序訪問一組表時(shí)，應(yīng)盡量約定以相同的順序訪問各表，對(duì)一個(gè)表而言，盡可能以固定的順序存取表中的行。這樣可以大大減少死鎖的機(jī)會(huì)。

盡量用相等條件訪問數(shù)據(jù)，這樣可以避免間隙鎖對(duì)并發(fā)插入的影響。

不要申請(qǐng)超過實(shí)際需要的鎖級(jí)別；除非必須，查詢時(shí)不要顯示加鎖。

對(duì)于一些特定的事務(wù)，可以使用表鎖來提高處理速度或減少死鎖的可能。