InnoDB鎖問題

InnoDB鎖問題

 

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

背景知識

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

事務是由一組SQL語句組成的邏輯處理單元，事務具備如下4個屬性，一般簡稱爲事務的ACID屬性。

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

l         一致性（Consistent）：在事務開始和完成時，數據都必須保持一致狀態。這意味着全部相關的數據規則都必須應用於事務的修改，以保持數據的完整性；事務結束時，全部的內部數據結構（如B樹索引或雙向鏈表）也都必須是正確的。

l         隔離性（Isolation）：數據庫系統提供必定的隔離機制，保證事務在不受外部併發操做影響的「獨立」環境執行。這意味着事務處理過程當中的中間狀態對外部是不可見的，反之亦然。

l         持久性（Durable）：事務完成以後，它對於數據的修改是永久性的，即便出現系統故障也可以保持。

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

2．併發事務處理帶來的問題

相對於串行處理來講，併發事務處理能大大增長數據庫資源的利用率，提升數據庫系統的事務吞吐量，從而能夠支持更多的用戶。但併發事務處理也會帶來一些問題，主要包括如下幾種狀況。

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

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

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

l  幻讀（Phantom Reads）：一個事務按相同的查詢條件從新讀取之前檢索過的數據，卻發現其餘事務插入了知足其查詢條件的新數據，這種現象就稱爲「幻讀」。

3．事務隔離級別

在上面講到的併發事務處理帶來的問題中，「更新丟失」一般是應該徹底避免的。但防止更新丟失，並不能單靠數據庫事務控制器來解決，須要應用程序對要更新的數據加必要的鎖來解決，所以，防止更新丟失應該是應用的責任。

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

l  一種是在讀取數據前，對其加鎖，阻止其餘事務對數據進行修改。

l  另外一種是不用加任何鎖，經過必定機制生成一個數據請求時間點的一致性數據快照（Snapshot)，並用這個快照來提供必定級別（語句級或事務級）的一致性讀取。從用戶的角度來看，好象是數據庫能夠提供同一數據的多個版本，所以，這種技術叫作數據多版本併發控制（MultiVersion ConcurrencyControl，簡稱MVCC或MCC），也常常稱爲多版本數據庫。

數 據庫的事務隔離越嚴格，併發反作用越小，但付出的代價也就越大，由於事務隔離實質上就是使事務在必定程度上「串行化」進行，這顯然與「併發」是矛盾的。同 時，不一樣的應用對讀一致性和事務隔離程度的要求也是不一樣的，好比許多應用對「不可重複讀」和「幻讀」並不敏感，可能更關心數據併發訪問的能力。

爲 瞭解決「隔離」與「併發」的矛盾，ISO/ANSI SQL92定義了4個事務隔離級別，每一個級別的隔離程度不一樣，容許出現的反作用也不一樣，應用能夠根據本身的業務邏輯要求，經過選擇不一樣的隔離級別來平衡 「隔離」與「併發」的矛盾。表20-5很好地歸納了這4個隔離級別的特性。

表20-5                                            4種隔離級別比較

讀數據一致性及容許的併發反作用 隔離級別	讀數據一致性	髒讀	不可重複讀	幻讀
未提交讀（Read  uncommitted）	最低級別，只能保證不讀取物理上損壞的數據	是	是	是
已提交度（Read  committed）	語句級	否	是	是
可重複讀（Repeatable  read）	事務級	否	否	是
可序列化（Serializable）	最高級別，事務級	否	否	否

最 後要說明的是：各具體數據庫並不必定徹底實現了上述4個隔離級別，例如，Oracle只提供Readcommitted和Serializable兩個標準隔離級別，另外還提供本身定義的Read only隔離級別；SQL Server除支持上述ISO/ANSI SQL92定義的4個隔離級別外，還支持一個叫作「快照」的隔離級別，但嚴格來講它是一個用MVCC實現的Serializable隔離級別。MySQL 支持所有4個隔離級別，但在具體實現時，有一些特色，好比在一些隔離級別下是採用MVCC一致性讀，但某些狀況下又不是，這些內容在後面的章節中將會作進一步介紹。

獲取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的值比較高，還能夠經過設置InnoDBMonitors來進一步觀察發生鎖衝突的表、數據行等，並分析鎖爭用的緣由。

具體方法以下：

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

Query OK, 0 rows affected (0.14 sec)

而後就能夠用下面的語句來進行查看：

mysql> Show innodb status\G;

*************************** 1. row ***************************

 Type: InnoDB

 Name:

Status:

…

…

------------

TRANSACTIONS

------------

Trx id counter 0 117472192

Purge done for trx's n:o < 0 117472190 undo n:o< 0 0

History list length 17

Total number of lock structs in row lock hash table 0

LIST OF TRANSACTIONS FOR EACH SESSION:

---TRANSACTION 0 117472185, not started, process no11052, OS thread id 1158191456

MySQL thread id 200610, query id 291197 localhost root

---TRANSACTION 0 117472183, not started, process no11052, OS thread id 1158723936

MySQL thread id 199285, query id 291199 localhost root

Show innodb status

…

監視器能夠經過發出下列語句來中止查看：

mysql> DROP TABLE innodb_monitor;

Query OK, 0 rows affected (0.05 sec)

設 置監視器後，在SHOW INNODB STATUS的顯示內容中，會有詳細的當前鎖等待的信息，包括表名、鎖類型、鎖定記錄的狀況等，便於進行進一步的分析和問題的肯定。打開監視器之後，默認狀況下每15秒會向日志中記錄監控的內容，若是長時間打開會致使.err文件變得很是的巨大，因此用戶在確認問題緣由以後，要記得刪除監控表以關閉監視器，或者經過使用「--console」選項來啓動服務器以關閉寫日誌文件。

InnoDB的行鎖模式及加鎖方法

InnoDB實現瞭如下兩種類型的行鎖。

l  共享鎖（S）：容許一個事務去讀一行，阻止其餘事務得到相同數據集的排他鎖。

l  排他鎖（X)：容許得到排他鎖的事務更新數據，阻止其餘事務取得相同數據集的共享讀鎖和排他寫鎖。

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

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

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

上述鎖模式的兼容狀況具體如表20-6所示。

表20-6                                           InnoDB行鎖模式兼容性列表

請求鎖模式 是否兼容 當前鎖模式	X	IX	S	IS
X	衝突	衝突	衝突	衝突
IX	衝突	兼容	衝突	兼容
S	衝突	衝突	兼容	兼容
IS	衝突	兼容	兼容	兼容

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

意向鎖是InnoDB自動加的，不需用戶干預。對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數據集加排他鎖（X)；對於普通SELECT語句，InnoDB不會加任何鎖；事務能夠經過如下語句顯示給記錄集加共享鎖或排他鎖。

共享鎖（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方式得到排他鎖。

在如表20-7所示的例子中，使用了SELECT ... IN SHARE MODE加鎖後再更新記錄，看看會出現什麼狀況，其中actor表的actor_id字段爲主鍵。

表20-7                    InnoDB存儲引擎的共享鎖例子

session_1	session_2
mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from  actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.00 sec)	mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from  actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.00 sec)
當前session對actor_id=178的記錄加share mode 的共享鎖： mysql> select actor_id,first_name,last_name from  actor where actor_id = 178 lock in share mode; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.01 sec)
	其餘session仍然能夠查詢記錄，並也能夠對該記錄加share  mode的共享鎖： mysql> select actor_id,first_name,last_name from  actor where actor_id = 178 lock in share mode; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.01 sec)
當前session對鎖定的記錄進行更新操做，等待鎖： mysql> update actor set last_name = 'MONROE T' where  actor_id = 178; 等待
	其餘session也對該記錄進行更新操做，則會致使死鎖退出： mysql> update actor set last_name = 'MONROE T' where  actor_id = 178; ERROR 1213 (40001): Deadlock found when trying to get  lock; try restarting transaction
得到鎖後，能夠成功更新： mysql> update actor set last_name = 'MONROE T' where  actor_id = 178; Query OK, 1 row affected (17.67 sec) Rows matched: 1  Changed: 1  Warnings: 0

當使用SELECT...FORUPDATE加鎖後再更新記錄，出現如表20-8所示的狀況。

表20-8                              InnoDB存儲引擎的排他鎖例子

session_1	session_2
mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from  actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.00 sec)	mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from  actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.00 sec)
當前session對actor_id=178的記錄加for update的共享鎖： mysql> select actor_id,first_name,last_name from  actor where actor_id = 178 for update; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.00 sec)
	其餘session能夠查詢該記錄，可是不能對該記錄加共享鎖，會等待得到鎖： mysql> select actor_id,first_name,last_name from  actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE    | +----------+------------+-----------+ 1 row in set (0.00 sec) mysql> select actor_id,first_name,last_name from  actor where actor_id = 178 for update; 等待
當前session能夠對鎖定的記錄進行更新操做，更新後釋放鎖： mysql> update actor set last_name = 'MONROE T' where  actor_id = 178; Query OK, 1 row affected (0.00 sec) Rows matched: 1  Changed: 1  Warnings: 0 mysql> commit; Query OK, 0 rows affected (0.01 sec)
	其餘session得到鎖，獲得其餘session提交的記錄： mysql> select actor_id,first_name,last_name from  actor where actor_id = 178 for update; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178      |  LISA       | MONROE T  | +----------+------------+-----------+ 1 row in set (9.59 sec)

InnoDB行鎖實現方式

InnoDB行鎖是經過給索引上的索引項加鎖來實現的，這一點MySQL與Oracle不一樣，後者是經過在數據塊中對相應數據行加鎖來實現的。InnoDB這種行鎖實現特色意味着：只有經過索引條件檢索數據，InnoDB才使用行級鎖，不然，InnoDB將使用表鎖！

在實際應用中，要特別注意InnoDB行鎖的這一特性，否則的話，可能致使大量的鎖衝突，從而影響併發性能。下面經過一些實際例子來加以說明。

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

在如表20-9所示的例子中，開始tab_no_index表沒有索引：

mysql> create table tab_no_index(id int,name varchar(10))engine=innodb;

Query OK, 0 rows affected (0.15 sec)

mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');

Query OK, 4 rows affected (0.00 sec)

Records: 4  Duplicates: 0  Warnings: 0

表20-9              InnoDB存儲引擎的表在不使用索引時使用表鎖例子

session_1	session_2
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_no_index where id = 1 ; +------+------+ | id   | name | +------+------+ | 1    | 1    | +------+------+ 1 row in set (0.00 sec)	mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_no_index where id = 2 ; +------+------+ | id   | name | +------+------+ | 2    | 2    | +------+------+ 1 row in set (0.00 sec)
mysql> select * from tab_no_index where id = 1 for  update; +------+------+ | id   | name | +------+------+ | 1    | 1    | +------+------+ 1 row in set (0.00 sec)
	mysql> select * from tab_no_index where id = 2 for  update; 等待

在 如表20-9所示的例子中，看起來session_1只給一行加了排他鎖，但session_2在請求其餘行的排他鎖時，卻出現了鎖等待！緣由就是在沒有 索引的狀況下，InnoDB只能使用表鎖。當咱們給其增長一個索引後，InnoDB就只鎖定了符合條件的行，如表20-10所示。

建立tab_with_index表，id字段有普通索引：

mysql> create table tab_with_index(id int,name varchar(10))engine=innodb;

Query OK, 0 rows affected (0.15 sec)

mysql> alter table tab_with_index add index id(id);

Query OK, 4 rows affected (0.24 sec)

Records: 4  Duplicates: 0  Warnings: 0

表20-10                               InnoDB存儲引擎的表在使用索引時使用行鎖例子

session_1	session_2
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_with_index where id = 1 ; +------+------+ | id   | name | +------+------+ | 1    | 1    | +------+------+ 1 row in set (0.00 sec)	mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_with_index where id = 2 ; +------+------+ | id   | name | +------+------+ | 2    | 2    | +------+------+ 1 row in set (0.00 sec)
mysql> select * from tab_with_index where id = 1 for  update; +------+------+ | id   | name | +------+------+ | 1    | 1    | +------+------+ 1 row in set (0.00 sec)
	mysql> select * from tab_with_index where id = 2 for  update; +------+------+ | id   | name | +------+------+ | 2    | 2    | +------+------+ 1 row in set (0.00 sec)

（2）因爲MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，因此雖然是訪問不一樣行的記錄，可是若是是使用相同的索引鍵，是會出現鎖衝突的。應用設計的時候要注意這一點。

在如表20-11所示的例子中，表tab_with_index的id字段有索引，name字段沒有索引：

mysql> alter table tab_with_index drop index name;

Query OK, 4 rows affected (0.22 sec)

Records: 4  Duplicates: 0  Warnings: 0

mysql> insert into tab_with_index  values(1,'4');

Query OK, 1 row affected (0.00 sec)

mysql> select * from tab_with_index where id = 1;

+------+------+

| id   | name |

+------+------+

| 1    | 1    |

| 1    | 4    |

+------+------+

2 rows in set (0.00 sec)

表20-11               InnoDB存儲引擎使用相同索引鍵的阻塞例子

session_1	session_2
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)	mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 and  name = '1' for update; +------+------+ | id   | name | +------+------+ | 1    | 1    | +------+------+ 1 row in set (0.00 sec)
	雖然session_2訪問的是和session_1不一樣的記錄，可是由於使用了相同的索引，因此須要等待鎖： mysql> select * from tab_with_index where id = 1 and  name = '4' for update; 等待

（3）當表有多個索引的時候，不一樣的事務可使用不一樣的索引鎖定不一樣的行，另外，不管是使用主鍵索引、惟一索引或普通索引，InnoDB都會使用行鎖來對數據加鎖。

在如表20-12所示的例子中，表tab_with_index的id字段有主鍵索引，name字段有普通索引：

mysql> alter table tab_with_index add index name(name);

Query OK, 5 rows affected (0.23 sec)

Records: 5  Duplicates: 0  Warnings: 0

表20-12                                 InnoDB存儲引擎的表使用不一樣索引的阻塞例子

session_1	session_2
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)	mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec)
mysql> select * from tab_with_index where id = 1 for  update; +------+------+ | id   | name | +------+------+ | 1    | 1    | | 1    | 4    | +------+------+ 2 rows in set (0.00 sec)
	Session_2使用name的索引訪問記錄，由於記錄沒有被索引，因此能夠得到鎖： mysql> select * from tab_with_index where name = '2'  for update; +------+------+ | id   | name | +------+------+ | 2    | 2    | +------+------+ 1 row in set (0.00 sec)
	因爲訪問的記錄已經被session_1鎖定，因此等待得到鎖。： mysql> select * from tab_with_index where name = '4'  for update;

（4） 即使在條件中使用了索引字段，可是否使用索引來檢索數據是由MySQL經過判斷不一樣執行計劃的代價來決定的，若是MySQL認爲全表掃描效率更高，好比對一些很小的表，它就不會使用索引，這種狀況下InnoDB將使用表鎖，而不是行鎖。所以，在分析鎖衝突時，別忘了檢查SQL的執行計劃，以確認是否真正使 用了索引。關於MySQL在什麼狀況下不使用索引的詳細討論，參見本章「索引問題」一節的介紹。

在下面的例子中，檢索值的數據類型與索引字段不一樣，雖然MySQL可以進行數據類型轉換，但卻不會使用索引，從而致使InnoDB使用表鎖。經過用explain檢查兩條SQL的執行計劃，咱們能夠清楚地看到了這一點。

例子中tab_with_index表的name字段有索引，可是name字段是varchar類型的，若是where條件中不是和varchar類型進行比較，則會對name進行類型轉換，而執行的全表掃描。

mysql> alter table tab_no_index add index name(name);

Query OK, 4 rows affected (8.06 sec)

Records: 4  Duplicates: 0  Warnings: 0

mysql> explain select * from tab_with_index where name = 1 \G

*************************** 1. row ***************************

          id: 1

 select_type: SIMPLE

       table: tab_with_index

        type: ALL

possible_keys: name

         key: NULL

     key_len: NULL

         ref: NULL

        rows: 4

       Extra: Using where

1 row in set (0.00 sec)

mysql> explain select * from tab_with_index where name = '1' \G

*************************** 1. row ***************************

          id: 1

 select_type: SIMPLE

       table: tab_with_index

        type: ref

possible_keys: name

         key: name

     key_len: 23

         ref: const

        rows: 1

       Extra: Using where

1 row in set (0.00 sec)

 

InnoDB Record, Gap, andNext-Key Locks

在INNODB中，record-level lock大體有三種：Record, Gap, and Next-KeyLocks。

簡單的說，Record Lock就是鎖住某一行記錄；

而Gap Lock會鎖住某一段範圍中的記錄；Next-key Lock 則是前二者加起來的效果。

 

下面是MYSQL官方文檔中相關內容的連接

https://dev.mysql.com/doc/refman/5.6/en/innodb-record-level-locks.html

 

幻影讀問題

典型的幻影讀問題以下，即在事務A的兩次讀過程當中，有事務B插入了一條新的記錄，致使同一事務兩次讀出的內容不一樣。具體見下圖Fig.5.28.

 

 

Gap Lock

MySQL經過鎖定記錄，以及先後記錄間的間隙(Gap)來阻止上面的事件發生。即所謂Gap Lock。 它會致使了鎖定範圍的增大，在某些狀況下可能會形成一些不符合預期的現象。下面是一個簡單的測試例子，先對Gap Lock有個感性的認識

mysql> desc ts_column_log_test

   -> ;

+------------+-------------+------+-----+---------------------+----------------+

| Field     |Type        | Null | Key|Default            |Extra          |

+------------+-------------+------+-----+---------------------+----------------+

|id        |int(11)     | NO   | PRI|NULL               |auto_increment |

| col_id    |int(11)     | NO   | MUL|NULL               |               |

| start_time | timestamp   |NO  |     | 0000-00-0000:00:00|               |

| end_time   |timestamp   |NO   |     |0000-00-0000:00:00|               |

| data_time  | timestamp   |NO  |     | 0000-00-0000:00:00|               |

| status     |varchar(30) |NO   |    |NULL               |               |

+------------+-------------+------+-----+---------------------+----------------+

6 rows in set (0.01 sec)

 

mysql> select * from ts_column_log_test;

+----+--------+---------------------+---------------------+---------------------+---------+

| id | col_id|start_time         |end_time           |data_time          |status  |

+----+--------+---------------------+---------------------+---------------------+---------+

|  1 |      2| 2011-12-1311:51:11 | 2011-12-13 11:51:11 | 2011-12-09 00:00:00 | running |

|  2 |     20 |2011-12-13 11:51:16| 2011-12-13 11:51:16 | 2011-12-09 00:00:00 | running |

|  3 |    120 |2011-12-13 11:51:20 |2011-12-13 11:51:20 | 2011-12-09 00:00:00 | running |

+----+--------+---------------------+---------------------+---------------------+---------+

3 rows in set (0.00 sec)

 

開啓兩個不一樣的會話，分別執行一些語句觀察一下結果：

session1

mysql> set autocommit=0;

mysql> delete from ts_column_log_testwhere col_id=10;

Query OK, 0 rows affected(0.00sec)        --此時[2,20)這個區間內的記錄都已經被GAP LOCK鎖住了，若是在其餘事務中嘗試插入這些值，則會等待

 

session2

mysql> set autocommit=0;

mysql> INSERT INTO ts_column_log_test(col_id,start_time, end_time, data_time, status) VALUES (1, NULL, NULL,'20111209','running');  --成功

...

mysql> INSERT INTO ts_column_log_test(col_id,start_time, end_time, data_time, status) VALUES (2, NULL, NULL,'20111209','running');  --等待

...

mysql> INSERT INTO ts_column_log_test(col_id,start_time, end_time, data_time, status) VALUES (19, NULL, NULL,'20111209','running');  --等待

...

 

上面的實驗很簡單，你們能夠本身測一下。這裏解釋一下會產生這種現象的緣由：session1中的delete語句中指定條件where col_id=10，這時MYSQL會去掃描索引，可是這個時候delete語句獲取的不是一個RECORD LOCK，而是一個NEXT-KEY LOCK。以當前值（10）爲例，會向左掃描至col_id=2這條記錄，向右掃描至col_id=20這條記錄，鎖定區間爲前閉後開，即[2,20)。

下面是摘自官方手冊裏的一句話：

DELETE FROM ... WHERE ... sets an exclusivenext-key lock onevery record the search encounters.

下面的連接裏面有INNODB中各類不一樣的語句可能持有哪些鎖的解釋

http://dev.mysql.com/doc/refman/5.6/en/innodb-locks-set.html

 

間隙鎖（Next-Key鎖）

有了上面的Gap Lock的介紹做爲鋪墊，我想下面的內容應該容易理解多了。

 

當咱們用範圍條件而不是相等條件檢索數據，並請求共享或排他鎖時，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也會使用間隙鎖！

在如表20-13所示的例子中，假如emp表中只有101條記錄，其empid的值分別是1,2,......,100,101。

表20-13               InnoDB存儲引擎的間隙鎖阻塞例子

session_1	session_2
mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation  | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec) mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec)	mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation  | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec) mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec)
當前session對不存在的記錄加for update的鎖： mysql> select * from emp where empid = 102 for  update; Empty set (0.00 sec)
	這時，若是其餘session插入empid爲201的記錄（注意：這條記錄並不存在），也會出現鎖等待： mysql>insert into emp(empid,...) values(201,...); 阻塞等待
Session_1 執行rollback： mysql> rollback; Query OK, 0 rows affected (13.04 sec)
	因爲其餘session_1回退後釋放了Next-Key鎖，當前session能夠得到鎖併成功插入記錄： mysql>insert into emp(empid,...) values(201,...); Query OK, 1 row affected (13.35 sec)

 

 

幻讀致使複製失效的問題

 

 

refer：http://blog.51cto.com/louisyang/1373155