關於MySQL InnoDB 鎖行仍是鎖表

http://www.cnblogs.com/mingxuan/archive/2011/10/11/2207560.html

關於mysql的鎖行仍是鎖表，這個問題，今天算是有了一點頭緒，mysql 中 innodb是鎖行的，可是項目中竟然出現了死鎖，鎖表的狀況。爲何呢？先看一下這篇文章。

 

作項目時因爲業務邏輯的須要，必須對數據表的一行或多行加入行鎖，舉個最簡單的例子，圖書借閱系統。假設 id=1 的這本書庫存爲 1 ，可是有 2 我的同時來借這本書，此處的邏輯爲

Select   restnum from book where id =1 ;          #1
-- 若是 restnum 大於 0 ，執行 update  
Update   book set restnum=restnum-1 where id=1 ;  #2
Select   restnum from book where id =1 ;          #3
-- 若是 restnum 大於 0 ，執行 update
Update   book set restnum=restnum-1 where id=1;   #4

這樣，第二我的執行到 select 語句的時候就會處於等待狀態直到第一我的執行 commit 。從而保證了第二我的不會讀到第一我的修改前的數據。問題就來了，當 2 我的同時來借的時候，有可能第一我的執行 select 語句的時候，第二我的插了進來，在第一我的沒來得及更新 book 表的時候，第二我的查到數據了，實際上是髒數據，由於第一我的會把 restnum 值減 1 ，所以第二我的原本應該是查到 id=1 的書 restnum 爲 0 了，所以不會執行 update ，而會告訴它 id=1 的書沒有庫存了，但是數據庫哪懂這些，數據庫只負責執行一條條 SQL 語句，它才無論中間有沒有其餘 sql 語句插進來，它也不知道要把一個 session 的 sql 語句執行完再執行另外一個 session 的。所以會致使併發的時候 restnum 最後的結果爲 -1 ，顯然這是不合理的(簡單地說,由於不是原子操做,就是出現先執行了#1和#3,再執行#2/#4)，因此，纔出現鎖的概念， Mysql 使用 innodb 引擎能夠經過索引對數據行加鎖。以上借書的語句變爲：

Begin;  
Select   restnum from book where id =1 for   update ;  
-- 給 id=1 的行加上排它鎖且 id 有索引  
Update   book set restnum=restnum-1 where id=1 ;  
Commit;  
Begin;
Select   restnum from book where id =1 for   update ;
-- 給 id=1 的行加上排它鎖且 id 有索引
Update   book set restnum=restnum-1 where id=1 ;
Commit;

那這樣是否是萬無一失了呢，答案是否認的。看下面的例子。

 

跟我一步一步來，先創建表

CREATE TABLE `book` (   
`id` int(11) NOT NULL auto_increment,   
`num` int(11) default NULL,   
`name` varchar(0) default NULL,   
PRIMARY KEY (`id`),   
KEY `asd` (`num`)   
) ENGINE=InnoDB DEFAULT CHARSET=gbk  
CREATE TABLE `book` (
`id` int(11) NOT NULL auto_increment,
`num` int(11) default NULL,
`name` varchar(0) default NULL,
PRIMARY KEY (`id`),
KEY `asd` (`num`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk

而後插入數據，運行，其中 num 字段加了索引

insert into book(num) values(11),(11),(11),(11),(11);   
insert into book(num) values(22),(22),(22),(22),(22);  
insert into book(num) values(11),(11),(11),(11),(11);
insert into book(num) values(22),(22),(22),(22),(22);

********************************************************************
而後打開 2 個 mysql 控制檯窗口，其實就是創建 2 個 session 作併發操做

在第一個 session 裏運行：

begin;
select * from book where num=11 for update;

出現結果：

+----+-----+------+
| id | num | name |
+----+-----+------+
| 11 | 11 | NULL |
| 12 | 11 | NULL |
| 13 | 11 | NULL |
| 14 | 11 | NULL |
| 15 | 11 | NULL |
+----+-----+------+
5 rows in set

而後在第二個 session 裏運行：

begin;
select * from book where num=22 for update;

出現結果：

+----+-----+------+
| id | num | name |
+----+-----+------+
| 16 | 22 | NULL |
| 17 | 22 | NULL |
| 18 | 22 | NULL |
| 19 | 22 | NULL |
| 20 | 22 | NULL |
+----+-----+------+
5 rows in set

好了，到這裏什麼問題都沒有，是吧，但是接下來問題就來了，你們請看：
回到第一個 session ，運行：

update book set name='abc' where num=11;

********************************************************************************************
問題來了， session 居然處於等待狀態 ，但是 num=11 的行不是被第一個 session 本身鎖住的麼，爲何不能更新呢？好了，打這裏你們也許有本身的答案，先別急，再請看一下操做。

把 2 個 session 都關閉，而後運行：

delete from book where num=11 limit 3;   
delete from book where num=22 limit 3;  
delete from book where num=11 limit 3;
delete from book where num=22 limit 3;

其實就是把 num=11 和 22 的記錄各刪去 3 行，
而後重複 「***********************」 之間的操做
居然發現，運行 update book set name='abc' where num=11; 後，有結果出現了，說明沒有被鎖住，
這是爲何呢，難道 2 行數據和 5 行數據，對 MySQL 來講，會產生鎖行和鎖表兩種狀況嗎。通過跟網友討論和翻閱資料，仔細分析後發現：

在以上實驗數據做爲測試數據的狀況下，因爲 num 字段重複率過高，只有 2 個值，分別是 11 和 12. 而數據量相對於這兩個值來講倒是比較大的，是 10 條， 5 倍的關係。
那麼 mysql 在解釋 sql 的時候，會忽略索引，由於它的優化器發現：即便使用了索引，仍是要作全表掃描，故而放棄了索引，也就沒有使用行鎖，卻使用了表鎖。簡單的講，就是 MYSQL 無視了你的索引，它以爲與其行鎖，還不如直接表鎖，畢竟它以爲表鎖所花的代價比行鎖來的小。以上問題即使你使用了 force index 強制索引，結果仍是同樣，永遠都是表鎖。

因此 mysql 的行鎖用起來並非那麼爲所欲爲的，必需要考慮索引。再看下面的例子。

select id from items where id in (select id from items where id <6) for update;    
--id字段加了索引  
select id from items where id in (1,2,3,4,5) for update;
select id from items where id in (select id from items where id <6) for update;
--id字段加了索引
select id from items where id in (1,2,3,4,5) for update;

大部分會認爲結果同樣沒什麼區別，其實差異大了，區別就是第一條 sql 語句會產生表鎖，而第二個 sql 語句是行鎖，爲何呢？由於第一個 sql 語句用了子查詢外圍查詢故而沒使用索引，致使表鎖。

 

好了，回到借書的例子，因爲 id 是惟一的，因此沒什麼問題，可是若是有些表出現了索引有重複值，而且 mysql 會強制使用表鎖的狀況，那怎麼辦呢？通常來講只有從新設計表結構和用新的 SQL 語句實現業務邏輯，可是其實上面借書的例子還有一種辦法。請看下面代碼：

Set   sql_mode=  
'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';  
Begin;  
Select restnum from book where id =1   ; -- 取消排它鎖 , 設置 restnum 爲 unsigned  
Update   book set restnum=restnum-1 where id=1 ;  
If(update 執行成功 ) commit;  
Else   rollback;  
Set   sql_mode=
'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Begin;
Select restnum from book where id =1   ; -- 取消排它鎖 , 設置 restnum 爲 unsigned
Update   book set restnum=restnum-1 where id=1 ;
If(update 執行成功 ) commit;
Else   rollback;

上面是個小技巧，經過把數據庫模式臨時設置爲嚴格模式，當 restnum 被更新爲 -1 的時候，因爲 restnum 是 unsigned 類型的，所以 update 會執行失敗，不管第二個 session 作了什麼數據庫操做，都會被回滾，從而確保了數據的正確性，這個目的只是爲了防止併發的時候極小機率出現的 2 個 session 的 sql 語句嵌套執行致使數據髒讀。固然最好的辦法仍是修改表結構和 sql 語句，讓 MYSQL 經過索引來加行鎖, MySQL 測試版本爲 5.0.75-log 和 5.1.36-community

因此，能夠總結出。Mysql innodb雖是鎖行的，可是若是沒有索引，或者索引如上，那就要鎖表了。