lock in share mode 就是共享鎖

如果事務對某行數據加上共享鎖之后，可進行讀寫操作；其他事務可以對該數據加共享鎖，但不能加排他鎖，且只能讀數據，不能修改數據。

某個事物想進行修改數據操作，那他必須等其他事物的共享鎖都釋放完畢才能進行修改操作

for update 排他鎖，就是行鎖

如果事務對數據加上排他鎖之后，則其他事務不能對該數據加任何的鎖。

獲取排他鎖的事務既能讀取數據，也能修改數據。

注：普通 select 語句默認不加鎖，而CUD操作默認加排他鎖。

例子

下面例子的前提都是針對同一行數據。

1.同一行數據為前提，兩個事物都進行共享鎖查詢

2.同一行數據為前提，一個事物進行共享鎖查詢，另一個事物進行修改

第一個占有著共享鎖，第二個事物沒法更新，必須等第一個事物釋放才能進行更新

3.同一行數據為前提，一個進行共享鎖查詢，另一個先進行共享鎖查詢，然后update

同第二種，修改的事物就一直在轉圈圈，等待事物1提交。事物1不提交，那事物2只能等到超時返回錯誤。

4.同一行數據為前提，當事物一獲得共享鎖，另一個事物是否可以獲得排它鎖

答案是不能，事物二就一直轉圈圈，等待1的釋放

結論：同一行數據為前提，當一個事物獲得共享鎖，另一個事物可以獲得共享鎖進行讀操作，但不能進行修改操作，想要修改必須等其他的共享鎖釋放完畢。還有一個事物獲得了共享鎖，另一個事物不能獲得排它鎖

5.同一行數據為前提，一個事物獲取到排他鎖，另一個事物進行查詢

結果是可以的，一個獲取排它鎖，另一個進行普通查詢

6.同一行數據為前提，一個事物獲取到排他鎖，另一個事物進行共享鎖的獲取

結果如圖2，愛的魔力轉圈圈，就一直卡在那里

7.同一行數據為前提，一個事物獲取排它鎖，另一個事物是否可以進行修改

結果如圖2，愛的魔力轉圈圈，就一直卡在那里

8.同一行數據為前提，一個事物獲取排它鎖，另一個是否可以獲取排它鎖

結果如圖2，愛的魔力轉圈圈，就一直卡在那里

結論：當前事務獲取某行數據排他鎖后，其他事務是否可以對該行數據進行讀寫操作和獲取共享鎖：其他事務可以讀，不可以獲取共享鎖，不可以寫

這里再給讀者科普一點，行鎖和索引的關系：查詢字段未加索引（主鍵索引、普通索引等）時，使用表鎖

注：InnoDB行級鎖基于索引實現。

未加索引時，兩種行鎖情況為（使用表鎖）：

• 事務1獲取某行數據共享鎖，其他事務可以獲取不同行數據的共享鎖，不可以獲取不同行數據的排他鎖
• 事務1獲取某行數據排他鎖，其他事務不可以獲取不同行數據的共享鎖、排他鎖

加索引后，兩種行鎖為（使用行鎖）：

• 事務1獲取某行數據共享鎖，其他事務可以獲取不同行數據的排他鎖
• 事務1獲取某行數據排他鎖，其他事務可以獲取不同行數據的共享鎖、排他鎖

表結果：

CREATE TABLE `pf_banner` (
  `id` bigint(22) NOT NULL AUTO_INCREMENT,
  `num` int(11) DEFAULT NULL,
  `title` varchar(80) DEFAULT NULL,
  `url` varchar(255) DEFAULT NULL,
  `img` varchar(255) DEFAULT NULL,
  `status` tinyint(4) DEFAULT '1' COMMENT '狀態(tài) 1：顯示 -1不顯示',
  `create_time` datetime DEFAULT NULL,
  `modify_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='banner位圖片'

例子

1.未加索引，事務1獲取某行數據共享鎖，事務2更新不同行數據阻塞：

2.未加索引，事務1獲取某行數據共享鎖，事務2獲取不同行數據共享鎖成功：

3.未加索引，事務1獲取某行數據排他鎖，事務2獲取不同行數據共享鎖阻塞：

4.未加索引，事務1獲取某行數據排他鎖，事務2獲取不同行數據排他鎖阻塞：

加索引后表結構：

CREATE TABLE `pf_banner` (
  `id` bigint(22) NOT NULL AUTO_INCREMENT,
  `num` int(11) DEFAULT NULL,
  `title` varchar(80) DEFAULT NULL,
  `url` varchar(255) DEFAULT NULL,
  `img` varchar(255) DEFAULT NULL,
  `status` tinyint(4) DEFAULT '1' COMMENT '狀態(tài) 1：顯示 -1不顯示',
  `create_time` datetime DEFAULT NULL,
  `modify_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_num` (`num`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='banner位圖片'

1.加索引后，事務1獲取某行數據共享鎖，事務2可以更新不同行數據：

2.加索引后，事務1獲取某行數據共享鎖，事務2獲取不同行數據共享鎖成功：

3.加索引后，事務1獲取某行數據排他鎖，事務2獲取不同行數據排他鎖成功：

4.加索引后，事務1獲取某行數據排他鎖，事務2獲取不同行數據共享鎖成功：

科普小知識2：索引數據重復率太高會導致全表掃描：當表中索引字段數據重復率太高，則MySQL可能會忽略索引，進行全表掃描，此時使用表鎖?？墒褂?force index 強制使用索引。

操作步驟

1.事務1，執(zhí)行鼠標選中的內容

2.事物2，執(zhí)行鼠標選中的內容

你會發(fā)現事物2會一直轉圈圈，其實在執(zhí)行update的時候，已經是表鎖了。導致事物2 進行行鎖的時候，需要等待事物1的釋放

現在，我們使用強制鎖進行更新操作。

當你使用強制索引的時候，就會發(fā)現更新成功了。

當然數據重復降低，也是能成功的

總結

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論