做項(xiàng)目時(shí)由于業(yè)務(wù)邏輯的需要，必須對數(shù)據(jù)表的一行或多行加入行鎖，舉個(gè)最簡單的例子，圖書借閱系統(tǒng)。假設(shè)?id=1?的這本書庫存為?1?，但是有?2?個(gè)人同時(shí)來借這本書，此處的邏輯為

Select restnum from book where id =1 ;

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

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

問題就來了，當(dāng)?2?個(gè)人同時(shí)來借的時(shí)候，有可能第一個(gè)人執(zhí)行?select?語句的時(shí)候，第二個(gè)人插了進(jìn)來，在第一個(gè)人沒來得及更新?book?表的時(shí)候，第二個(gè)人查到數(shù)據(jù)了，其實(shí)是臟數(shù)據(jù)，因?yàn)榈谝粋€(gè)人會把?restnum?值減?1?，因此第二個(gè)人本來應(yīng)該是查到?id=1?的書?restnum?為?0?了，因此不會執(zhí)行?update?，而會告訴它?id=1?的書沒有庫存?了，可是數(shù)據(jù)庫哪懂這些，數(shù)據(jù)庫只負(fù)責(zé)執(zhí)行一條條?SQL?語句，它才不管中間有沒有其他?sql?語句插進(jìn)來，它也不知道要把一個(gè)?session?的?sql?語句執(zhí)行完再執(zhí)行另一個(gè)?session的。因此會導(dǎo)致并發(fā)的時(shí)候?restnum?最后的結(jié)果為?-1?，顯然這是不合理的，所以，才出現(xiàn)鎖的概念，?Mysql?使用?innodb?引擎可以通過索引對數(shù)據(jù)行加鎖。以上借書的語句變?yōu)?#xff1a;Begin;

Select restnum from book where id =1 for update ;

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

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

Commit;

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

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

跟我一步一步來，先建立表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ù)，運(yùn)行，

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

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

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

********************************************************************

在第一個(gè)?session?里運(yùn)行：

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

然后在第二個(gè)?session?里運(yùn)行：

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

好了，到這里什么問題都沒有，是吧，可是接下來問題就來了，大家請看：

回到第一個(gè)?session?，運(yùn)行：

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

********************************************************************************************

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

把?2?個(gè)?session?都關(guān)閉，然后運(yùn)行：

delete from book where num=11 limit 3;

delete from book where num=22 limit 3;

其實(shí)就是把?num=11?和?22?的記錄各刪去?3?行，

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

竟然發(fā)現(xiàn)，運(yù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)友討論和翻閱資料，仔細(xì)分析后發(fā)現(xiàn)：

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

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

所以?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;

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

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

If(update 執(zhí)行成功 ) commit;

Else rollback;

上面是個(gè)小技巧，通過把數(shù)據(jù)庫模式臨時(shí)設(shè)置為嚴(yán)格模式，當(dāng)?restnum?被更新為?-1?的時(shí)候，由于?restnum?是?unsigned?類型的，因此?update?會執(zhí)行失敗，無論第二個(gè)session?做了什么數(shù)據(jù)庫操作，都會被回滾，從而確保了數(shù)據(jù)的正確性，這個(gè)目的只是為了防止并發(fā)的時(shí)候極小概率出現(xiàn)的?2?個(gè)?session?的?sql?語句嵌套執(zhí)行導(dǎo)致數(shù)據(jù)臟讀。當(dāng)然最好的辦法還是修改表結(jié)構(gòu)和?sql?語句，讓?MYSQL?通過索引來加行鎖,?MySQL?測試版本為?5.0.75-log?和?5.1.36-community

文章來源：http://blog.csdn.net/liyongqiao/article/details/52415516

本文由【waitig】發(fā)表在等英博客 本文固定鏈接：mysql 行級鎖 索引唯一值 歡迎關(guān)注本站官方公眾號，每日都有干貨分享！

點(diǎn)贊 (0)賞分享 (0)

總結(jié)

以上是生活随笔為你收集整理的mysql 行级锁 索引_mysql 行级锁 索引唯一值的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。