mysql悲观锁总结和实践--转
原文地址：http://chenzhou123520.iteye.com/blog/1860954
最近學(xué)習(xí)了一下數(shù)據(jù)庫的悲觀鎖和樂觀鎖，根據(jù)自己的理解和網(wǎng)上參考資料總結(jié)如下：
?
悲觀鎖介紹（百科）：
悲觀鎖，正如其名，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度，因此，在整個(gè)數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機(jī)制（也只有數(shù)據(jù)庫層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)）。
?
使用場景舉例：以MySQL InnoDB為例
商品goods表中有一個(gè)字段status，status為1代表商品未被下單，status為2代表商品已經(jīng)被下單，那么我們對某個(gè)商品下單時(shí)必須確保該商品status為1。假設(shè)商品的id為1。
?
1如果不采用鎖，那么操作方法如下：
//1.查詢出商品信息
select status from t_goods where id=1;
//2.根據(jù)商品信息生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status為2
update t_goods set status=2;
?
上面這種場景在高并發(fā)訪問的情況下很可能會(huì)出現(xiàn)問題。
前面已經(jīng)提到，只有當(dāng)goods status為1時(shí)才能對該商品下單，上面第一步操作中，查詢出來的商品status為1。但是當(dāng)我們執(zhí)行第三步Update操作的時(shí)候，有可能出現(xiàn)其他人先一步對商品下單把goods status修改為2了，但是我們并不知道數(shù)據(jù)已經(jīng)被修改了，這樣就可能造成同一個(gè)商品被下單2次，使得數(shù)據(jù)不一致。所以說這種方式是不安全的。
?
2使用悲觀鎖來實(shí)現(xiàn)：
在上面的場景中，商品信息從查詢出來到修改，中間有一個(gè)處理訂單的過程，使用悲觀鎖的原理就是，當(dāng)我們在查詢出goods信息后就把當(dāng)前的數(shù)據(jù)鎖定，直到我們修改完畢后再解鎖。那么在這個(gè)過程中，因?yàn)間oods被鎖定了，就不會(huì)出現(xiàn)有第三者來對其進(jìn)行修改了。
?
注：要使用悲觀鎖，我們必須關(guān)閉mysql數(shù)據(jù)庫的自動(dòng)提交屬性，因?yàn)镸ySQL默認(rèn)使用autocommit模式，也就是說，當(dāng)你執(zhí)行一個(gè)更新操作后，MySQL會(huì)立刻將結(jié)果進(jìn)行提交。
?
我們可以使用命令設(shè)置MySQL為非autocommit模式：
set autocommit=0;
?
設(shè)置完autocommit后，我們就可以執(zhí)行我們的正常業(yè)務(wù)了。具體如下：
//0.開始事務(wù)
begin;/begin work;/start transaction; (三者選一就可以)
//1.查詢出商品信息
select status from t_goods where id=1?for update;
//2.根據(jù)商品信息生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status為2
update t_goods set status=2;
//4.提交事務(wù)
commit;/commit work;
?
注：上面的begin/commit為事務(wù)的開始和結(jié)束，因?yàn)樵谇耙徊轿覀冴P(guān)閉了mysql的autocommit，所以需要手動(dòng)控制事務(wù)的提交，在這里就不細(xì)表了。
?
上面的第一步我們執(zhí)行了一次查詢操作：select status from t_goods where id=1 for update;
與普通查詢不一樣的是，我們使用了select…for update的方式，這樣就通過數(shù)據(jù)庫實(shí)現(xiàn)了悲觀鎖。此時(shí)在t_goods表中，id為1的 那條數(shù)據(jù)就被我們鎖定了，其它的事務(wù)必須等本次事務(wù)提交之后才能執(zhí)行。這樣我們可以保證當(dāng)前的數(shù)據(jù)不會(huì)被其它事務(wù)修改。
?
注：需要注意的是，在事務(wù)中，只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一筆數(shù)據(jù)時(shí)會(huì)等待其它事務(wù)結(jié)束后才執(zhí)行，一般SELECT ... 則不受此影響。拿上面的實(shí)例來說，當(dāng)我執(zhí)行select status from t_goods where id=1 for update;后。我在另外的事務(wù)中如果再次執(zhí)行select status from t_goods where id=1 for update;則第二個(gè)事務(wù)會(huì)一直等待第一個(gè)事務(wù)的提交，此時(shí)第二個(gè)查詢處于阻塞的狀態(tài)，但是如果我是在第二個(gè)事務(wù)中執(zhí)行select status from t_goods where id=1;則能正常查詢出數(shù)據(jù)，不會(huì)受第一個(gè)事務(wù)的影響。
?
補(bǔ)充：MySQL select…for update的Row Lock與Table Lock
上面我們提到，使用select…for update會(huì)把數(shù)據(jù)給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認(rèn)Row-Level Lock，所以只有「明確」地指定主鍵，MySQL 才會(huì)執(zhí)行Row lock (只鎖住被選取的數(shù)據(jù)) ，否則MySQL 將會(huì)執(zhí)行Table Lock (將整個(gè)數(shù)據(jù)表單給鎖住)。
?
舉例說明：
數(shù)據(jù)庫表t_goods，包括id,status,name三個(gè)字段，id為主鍵，數(shù)據(jù)庫中記錄如下;
mysql> select * from t_goods; +----+--------+------+ | id | status | name | +----+--------+------+ | 1 | 1 | 道具 | | 2 | 1 | 裝備 | +----+--------+------+ 2 rows in setmysql>注：為了測試數(shù)據(jù)庫鎖，我使用兩個(gè)console來模擬不同的事務(wù)操作，分別用console1、console2來表示。?
?
例1: (明確指定主鍵，并且有此數(shù)據(jù)，row lock)
console1：查詢出結(jié)果，但是把該條數(shù)據(jù)鎖定了
mysql> select * from t_goods where id=1 for update; +----+--------+------+ | id | status | name | +----+--------+------+ | 1 | 1 | 道具 | +----+--------+------+ 1 row in setmysql>console2：查詢被阻塞
mysql> select * from t_goods where id=1 for update;console2：如果console1長時(shí)間未提交，則會(huì)報(bào)錯(cuò)
mysql> select * from t_goods where id=1 for update; ERROR 1205 : Lock wait timeout exceeded; try restarting transaction例2: (明確指定主鍵，若查無此數(shù)據(jù)，無lock)
console1：查詢結(jié)果為空
mysql> select * from t_goods where id=3 for update; Empty setconsole2：查詢結(jié)果為空，查詢無阻塞，說明console1沒有對數(shù)據(jù)執(zhí)行鎖定
mysql> select * from t_goods where id=3 for update; Empty set例3: (無主鍵，table lock)
console1：查詢name=道具 的數(shù)據(jù)，查詢正常
mysql> select * from t_goods where name='道具' for update; +----+--------+------+ | id | status | name | +----+--------+------+ | 1 | 1 | 道具 | +----+--------+------+ 1 row in setmysql>console2：查詢name=裝備 的數(shù)據(jù)，查詢阻塞，說明console1把表給鎖住了
Sql代碼??console2：若console1長時(shí)間未提交，則查詢返回為空
Sql代碼???
例4: (主鍵不明確，table lock)
console1：查詢正常
Sql代碼??console2：查詢被阻塞，說明console1把表給鎖住了
Sql代碼???
例5: (主鍵不明確，table lock)
console1：
Sql代碼??console2：查詢被阻塞，說明console1把表給鎖住了
Sql代碼??console1：提交事務(wù)
Sql代碼??console2：console1事務(wù)提交后，console2查詢結(jié)果正常
Sql代碼???
以上就是關(guān)于數(shù)據(jù)庫主鍵對MySQL鎖級別的影響實(shí)例，需要注意的是，除了主鍵外，使用索引也會(huì)影響數(shù)據(jù)庫的鎖定級別
?
舉例：
我們修改t_goods表，給status字段創(chuàng)建一個(gè)索引
修改id為2的數(shù)據(jù)的status為2，此時(shí)表中數(shù)據(jù)為：
Sql代碼???
例6: (明確指定索引，并且有此數(shù)據(jù)，row lock)
console1：
Sql代碼??console2：查詢status=1的數(shù)據(jù)時(shí)阻塞，超時(shí)后返回為空，說明數(shù)據(jù)被console1鎖定了
Sql代碼??console2：查詢status=2的數(shù)據(jù)，能正常查詢，說明console1只鎖住了行，未鎖表
Sql代碼???
例7: (明確指定索引，若查無此數(shù)據(jù)，無lock)
console1：查詢status=3的數(shù)據(jù)，返回空數(shù)據(jù)
Sql代碼??console2：查詢status=3的數(shù)據(jù)，返回空數(shù)據(jù)
Sql代碼???
?
以上就是關(guān)于我對數(shù)據(jù)庫悲觀鎖的理解和總結(jié)，有不對的地方歡迎拍磚，下一次會(huì)帶來數(shù)據(jù)庫樂觀鎖的總結(jié)和實(shí)踐
?
參考資料：
MySQL事務(wù)與鎖定命令：http://www.docin.com/p-16805970.html
悲觀鎖：http://www.cnblogs.com/chenwenbiao/archive/2012/06/06/2537508.html?
?
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/6030084.html
總結(jié)
以上是生活随笔為你收集整理的mysql悲观锁总结和实践--转的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： mysql表名查询sql
- 下一篇： mysql乐观锁总结和实践--转