以下的文章主要向大家介紹的是MySQL行鎖的深入研究，前今天我們在做項目時因為業(yè)務(wù)邏輯的需要，我們應(yīng)對數(shù)據(jù)表的一行或多行加入MySQL行鎖，舉個最簡單的例子，圖書借閱系統(tǒng)。假設(shè) id=1 的這本書庫存為 1 ，但是有 2 個人同時來借這本書，此處的邏輯為，

view plaincopy to clipboardprint?  
Select restnum from book where id =1 ;   

如果 restnum 大于 0 ，執(zhí)行 update

Update book set restnumrestnum=restnum-1 where id=1 ;  

問題就來了，當(dāng) 2 個人同時來借的時候，有可能第一個人執(zhí)行 select 語句的時候，第二個人插了進來，在第一個人沒來得及更新 book 表的時候，第二個人查到數(shù)據(jù)了，其實是臟數(shù)據(jù)，因為第一個人會把 restnum 值減 1 ，因此第二個人本來應(yīng)該是查到 id=1 的書 restnum 為 0 了，因此不會執(zhí)行 update ，而會告訴它 id=1 的書沒有庫存 了，可是數(shù)據(jù)庫哪懂這些，數(shù)據(jù)庫只負責(zé)執(zhí)行一條條 SQL 語句，它才不管中間有沒有其他 sql 語句插進來，它也不知道要把一個 session 的 sql 語句執(zhí)行完再執(zhí)行另一個 session 的。

因此會導(dǎo)致并發(fā)的時候 restnum 最后的結(jié)果為 -1 ，顯然這是不合理的，所以，才出現(xiàn)鎖的概念， Mysql行鎖 使用 innodb 引擎可以通過索引 對數(shù)據(jù)行加鎖。以上借書的語句變?yōu)椋?/p>

view plaincopy to clipboardprint?  
Begin;   
Select restnum from book where id =1 for update ;   

給 id=1 的行加上排它鎖且 id 有索引

Update book set restnumrestnum=restnum-1 where id=1 ;   
Commit;  

這樣，第二個人執(zhí)行到 select 語句的時候就會處于等待狀態(tài)直到第一個人執(zhí)行 commit 。從而保證了第二個人不會讀到第一個人修改前的數(shù)據(jù)。

那這樣是不是萬無一失了呢，答案是否定的?？聪旅娴睦?。

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

view plaincopy to clipboardprint?  
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 字段加了索引

然后插入數(shù)據(jù)，運行，

view plaincopy to clipboardprint?  
insert into book(num) values(11),(11),(11),(11),(11);   
insert into book(num) values(22),(22),(22),(22),(22);   

然后打開 2 個 mysql行鎖 控制臺窗口，其實就是建立 2 個 session 做并發(fā)操作

在第一個 session 里運行：

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

出現(xiàn)結(jié)果：

+----+-----+------+   
| 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;  

出現(xiàn)結(jié)果：

+----+-----+------+   
| 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 竟然處于等待狀態(tài) ，可是 num=11 的行不是被第一個 session 自己鎖住的么，為什么不能更新呢？好了，打這里大家也許有自己的答案，先別急，再請看一下操作。

把 2 個 session 都關(guān)閉，然后運行：

view plaincopy to clipboardprint?  
delete from book where num=11 limit 3;   
delete from book where num=22 limit 3;   

其實就是把 num=11 和 22 的記錄各刪去 3 行，

然后重復(fù) “***********************” 之間的操作

竟然發(fā)現(xiàn)，運行 update book set name='abc' where num=11; 后，有結(jié)果出現(xiàn)了，說明沒有被鎖住，

這是為什么呢，難道 2 行數(shù)據(jù)和 5 行數(shù)據(jù)，對 MySQL 來說，會產(chǎn)生鎖行和鎖表兩種情況嗎 。經(jīng)過跟網(wǎng)友討論和翻閱資料，仔細分析后發(fā)現(xiàn)：

在以上實驗數(shù)據(jù)作為測試數(shù)據(jù)的情況下，由于 num 字段重復(fù)率太高，只有 2 個值，分別是 11 和 12. 而數(shù)據(jù)量相對于這兩個值來說卻是比較大的，是 10 條， 5 倍的關(guān)系。

那么 mysql 在解釋 sql 的時候，會忽略索引，因為它的優(yōu)化器發(fā)現(xiàn)：即使使用了索引，還是要做全表掃描，故而放棄了索引，也就沒有使用行鎖，卻使用了表鎖。 簡單的講，就是 MYSQL 無視了你的索引，它覺得與其行鎖，還不如直接表鎖，畢竟它覺得表鎖所花的代價比MySQL行鎖來的小。以上問題即便你使用了 force index 強制索引，結(jié)果還是一樣，永遠都是表鎖。

所以 mysql 的行鎖用起來并不是那么隨心所欲的，必須要考慮索引。再看下面的例子。

view plaincopy to clipboardprint?  
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;  

大部分會認(rèn)為結(jié)果一樣沒什么區(qū)別，其實差別大了，區(qū)別就是第一條 sql 語句會產(chǎn)生表鎖，而第二個 sql 語句是MySQL行鎖，為什么呢？因為第一個 sql 語句用了子查詢外圍查詢故而沒使用索引，導(dǎo)致表鎖。

好了，回到借書的例子，由于 id 是唯一的，所以沒什么問題，但是如果有些表出現(xiàn)了索引有重復(fù)值，并且 mysql 會強制使用表鎖的情況，那怎么辦呢？一般來說只有重新設(shè)計表結(jié)構(gòu)和用新的 SQL 語句實現(xiàn)業(yè)務(wù)邏輯，但是其實上面借書的例子還有一種辦法。請看下面代碼：

view plaincopy to clipboardprint?  
Set sql_mode=   
'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';   
Begin;   
Select restnum from book where id =1 ; -- 取消排它鎖 , 設(shè)置 restnum 為 unsigned   
Update book set restnumrestnum=restnum-1 where id=1 ;   
If(update 執(zhí)行成功 ) commit;   
Else rollback;   

上面是個小技巧，通過把數(shù)據(jù)庫模式臨時設(shè)置為嚴(yán)格模式，當(dāng) restnum 被更新為 -1 的時候，由于 restnum 是 unsigned 類型的，因此 update 會執(zhí)行失敗，無論第二個 session 做了什么數(shù)據(jù)庫操作，都會被回滾，從而確保了數(shù)據(jù)的正確性，這個目的只是為了防止并發(fā)的時候極小概率出現(xiàn)的 2 個 session 的 sql 語句嵌套執(zhí)行導(dǎo)致數(shù)據(jù)臟讀。

當(dāng)然最好的辦法還是修改表結(jié)構(gòu)和 sql 語句，讓 MYSQL 通過索引來加MySQL行鎖, MySQL 測試版本為 5.0.75-log 和 5.1.36-community

 【編輯推薦】

1. MySQL基本操作，新手入門寶典
2. 使用MySQL 數(shù)據(jù)庫出現(xiàn)的困難解決
3. MySQL mysqldump命令的正確應(yīng)用
4. MySQL移植問題的正確解決方案的描述
5. MySQL使用方法的經(jīng)驗大匯總