摘自
《深入淺出MySQL——數(shù)據(jù)庫(kù)開發(fā)、優(yōu)化與管理維護(hù)》20.3.3 InnoDB的行鎖模式及加鎖方法
InnoDB實(shí)現(xiàn)了以下兩種類型的行鎖。
? 共享鎖（S）：允許一個(gè)事務(wù)去讀一行，阻止其他事務(wù)獲得相同數(shù)據(jù)集的排他鎖。
? 排他鎖（X)：允許獲得排他鎖的事務(wù)更新數(shù)據(jù)，阻止其他事務(wù)取得相同數(shù)據(jù)集的共享讀鎖和排他寫鎖。
另外，為了允許行鎖和表鎖共存，實(shí)現(xiàn)多粒度鎖機(jī)制，InnoDB還有兩種內(nèi)部使用的意向鎖（Intention Locks），這兩種意向鎖都是表鎖。
? 意向共享鎖（IS）：事務(wù)打算給數(shù)據(jù)行加行共享鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加共享鎖前必須先取得該表的IS鎖。
? 意向排他鎖（IX）：事務(wù)打算給數(shù)據(jù)行加行排他鎖，事務(wù)在給一個(gè)數(shù)據(jù)行加排他鎖前必須先取得該表的IX鎖。
上述鎖模式的兼容情況具體如表20-6所示。
表20-6 InnoDB行鎖模式兼容性列表
請(qǐng)求鎖模式 是否兼容 當(dāng)前鎖模式 | X | IX | S | IS |
X | 沖突 | 沖突 | 沖突 | 沖突 |
IX | 沖突 | 兼容 | 沖突 | 兼容 |
S | 沖突 | 沖突 | 兼容 | 兼容 |
IS | 沖突 | 兼容 | 兼容 | 兼容 |
如果一個(gè)事務(wù)請(qǐng)求的鎖模式與當(dāng)前的鎖兼容，InnoDB就將請(qǐng)求的鎖授予該事務(wù)；反之，如果兩者不兼容，該事務(wù)就要等待鎖釋放。
意向鎖是InnoDB自動(dòng)加的，不需用戶干預(yù)。對(duì)于UPDATE、DELETE和INSERT語(yǔ)句，InnoDB會(huì)自動(dòng)給涉及數(shù)據(jù)集加排他鎖（X)；對(duì)于普通SELECT語(yǔ)句，InnoDB不會(huì)加任何鎖；事務(wù)可以通過以下語(yǔ)句顯示給記錄集加共享鎖或排他鎖。
·共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
·排他鎖（X)：SELECT * FROM table_name WHERE ... FOR UPDATE。
用SELECT ... IN SHARE MODE獲得共享鎖，主要用在需要數(shù)據(jù)依存關(guān)系時(shí)來(lái)確認(rèn)某行記錄是否存在，并確保沒有人對(duì)這個(gè)記錄進(jìn)行UPDATE或者DELETE操作。但是如果當(dāng)前事務(wù)也需要對(duì)該記錄進(jìn)行更新操作，則很有可能造成死鎖，對(duì)于鎖定行記錄后需要進(jìn)行更新操作的應(yīng)用，應(yīng)該使用SELECT... FOR UPDATE方式獲得排他鎖。
在如表20-7所示的例子中，使用了SELECT ... IN SHARE MODE加鎖后再更新記錄，看看會(huì)出現(xiàn)什么情況，其中actor表的actor_id字段為主鍵。
表20-7 InnoDB存儲(chǔ)引擎的共享鎖例子
session_1 | session_2 |
mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.00 sec) | mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.00 sec) |
當(dāng)前session對(duì)actor_id=178的記錄加share mode 的共享鎖： mysql> select actor_id,first_name,last_name from actor where actor_id = 178 lock in share mode; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.01 sec) | |
| 其他session仍然可以查詢記錄，并也可以對(duì)該記錄加share mode的共享鎖： mysql> select actor_id,first_name,last_name from actor where actor_id = 178 lock in share mode; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.01 sec) |
當(dāng)前session對(duì)鎖定的記錄進(jìn)行更新操作，等待鎖： mysql> update actor set last_name = 'MONROE T' where actor_id = 178; 等待 | |
| 其他session也對(duì)該記錄進(jìn)行更新操作，則會(huì)導(dǎo)致死鎖退出： mysql> update actor set last_name = 'MONROE T' where actor_id = 178; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction |
獲得鎖后，可以成功更新： mysql> update actor set last_name = 'MONROE T' where actor_id = 178; Query OK, 1 row affected (17.67 sec) Rows matched: 1 Changed: 1 Warnings: 0 | |
當(dāng)使用SELECT...FOR UPDATE加鎖后再更新記錄，出現(xiàn)如表20-8所示的情況。
表20-8 InnoDB存儲(chǔ)引擎的排他鎖例子
session_1 | session_2 |
mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.00 sec) | mysql> set autocommit = 0; Query OK, 0 rows affected (0.00 sec) mysql> select actor_id,first_name,last_name from actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.00 sec) |
當(dāng)前session對(duì)actor_id=178的記錄加for update的共享鎖： mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.00 sec) | |
| 其他session可以查詢?cè)撚涗洠遣荒軐?duì)該記錄加共享鎖，會(huì)等待獲得鎖： mysql> select actor_id,first_name,last_name from actor where actor_id = 178; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE | +----------+------------+-----------+ 1 row in set (0.00 sec) mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update; 等待 |
當(dāng)前session可以對(duì)鎖定的記錄進(jìn)行更新操作，更新后釋放鎖： mysql> update actor set last_name = 'MONROE T' where actor_id = 178; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 mysql> commit; Query OK, 0 rows affected (0.01 sec) | |
| 其他session獲得鎖，得到其他session提交的記錄： mysql> select actor_id,first_name,last_name from actor where actor_id = 178 for update; +----------+------------+-----------+ | actor_id | first_name | last_name | +----------+------------+-----------+ | 178 | LISA | MONROE T | +----------+------------+-----------+ 1 row in set (9.59 sec) |
20.3.4 InnoDB行鎖實(shí)現(xiàn)方式InnoDB行鎖是通過給索引上的索引項(xiàng)加鎖來(lái)實(shí)現(xiàn)的，這一點(diǎn)MySQL與Oracle不同，后者是通過在數(shù)據(jù)塊中對(duì)相應(yīng)數(shù)據(jù)行加鎖來(lái)實(shí)現(xiàn)的。InnoDB這種行鎖實(shí)現(xiàn)特點(diǎn)意味著：只有通過索引條件檢索數(shù)據(jù)，InnoDB才使用行級(jí)鎖，否則，InnoDB將使用表鎖！
在實(shí)際應(yīng)用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導(dǎo)致大量的鎖沖突，從而影響并發(fā)性能。下面通過一些實(shí)際例子來(lái)加以說(shuō)明。
（1）在不通過索引條件查詢的時(shí)候，InnoDB確實(shí)使用的是表鎖，而不是行鎖。
在如表20-9所示的例子中，開始tab_no_index表沒有索引：
mysql> create table tab_no_index(id int,name varchar(10)) engine=innodb;
Query OK, 0 rows affected (0.15 sec) mysql> insert into tab_no_index values(1,'1'),(2,'2'),(3,'3'),(4,'4');
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0 |
表20-9 InnoDB存儲(chǔ)引擎的表在不使用索引時(shí)使用表鎖例子
session_1 | session_2 |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_no_index where id = 1 ; +------+------+ | id | name | +------+------+ | 1 | 1 | +------+------+ 1 row in set (0.00 sec) | mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_no_index where id = 2 ; +------+------+ | id | name | +------+------+ | 2 | 2 | +------+------+ 1 row in set (0.00 sec) |
mysql> select * from tab_no_index where id = 1 for update; +------+------+ | id | name | +------+------+ | 1 | 1 | +------+------+ 1 row in set (0.00 sec) | |
| mysql> select * from tab_no_index where id = 2 for update; 等待 |
在如表20-9所示的例子中，看起來(lái)session_1只給一行加了排他鎖，但session_2在請(qǐng)求其他行的排他鎖時(shí)，卻出現(xiàn)了鎖等待！原因就是在沒有索引的情況下，InnoDB只能使用表鎖。當(dāng)我們給其增加一個(gè)索引后，InnoDB就只鎖定了符合條件的行，如表20-10所示。
創(chuàng)建tab_with_index表，id字段有普通索引：
mysql> create table tab_with_index(id int,name varchar(10)) engine=innodb;
Query OK, 0 rows affected (0.15 sec)
mysql> alter table tab_with_index add index id(id);
Query OK, 4 rows affected (0.24 sec)
Records: 4 Duplicates: 0 Warnings: 0 |
表20-10 InnoDB存儲(chǔ)引擎的表在使用索引時(shí)使用行鎖例子
session_1 | session_2 |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_with_index where id = 1 ; +------+------+ | id | name | +------+------+ | 1 | 1 | +------+------+ 1 row in set (0.00 sec) | mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from tab_with_index where id = 2 ; +------+------+ | id | name | +------+------+ | 2 | 2 | +------+------+ 1 row in set (0.00 sec) |
mysql> select * from tab_with_index where id = 1 for update; +------+------+ | id | name | +------+------+ | 1 | 1 | +------+------+ 1 row in set (0.00 sec) | |
| mysql> select * from tab_with_index where id = 2 for update; +------+------+ | id | name | +------+------+ | 2 | 2 | +------+------+ 1 row in set (0.00 sec) |
（2）由于MySQL的行鎖是針對(duì)索引加的鎖，不是針對(duì)記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用相同的索引鍵，是會(huì)出現(xiàn)鎖沖突的。應(yīng)用設(shè)計(jì)的時(shí)候要注意這一點(diǎn)。
在如表20-11所示的例子中，表tab_with_index的id字段有索引，name字段沒有索引：
mysql> alter table tab_with_index drop index name;
Query OK, 4 rows affected (0.22 sec)
Records: 4 Duplicates: 0 Warnings: 0 mysql> insert into tab_with_index values(1,'4');
Query OK, 1 row affected (0.00 sec) mysql> select * from tab_with_index where id = 1;
+------+------+
| id | name |
+------+------+
| 1 | 1 |
| 1 | 4 |
+------+------+
2 rows in set (0.00 sec) |
表20-11 InnoDB存儲(chǔ)引擎使用相同索引鍵的阻塞例子
session_1 | session_2 |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) | mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
mysql> select * from tab_with_index where id = 1 and name = '1' for update; +------+------+ | id | name | +------+------+ | 1 | 1 | +------+------+ 1 row in set (0.00 sec) | |
| 雖然session_2訪問的是和session_1不同的記錄，但是因?yàn)槭褂昧讼嗤乃饕孕枰却i： mysql> select * from tab_with_index where id = 1 and name = '4' for update; 等待 |
（3）當(dāng)表有多個(gè)索引的時(shí)候，不同的事務(wù)可以使用不同的索引鎖定不同的行，另外，不論是使用主鍵索引、唯一索引或普通索引，InnoDB都會(huì)使用行鎖來(lái)對(duì)數(shù)據(jù)加鎖。
在如表20-12所示的例子中，表tab_with_index的id字段有主鍵索引，name字段有普通索引：
mysql> alter table tab_with_index add index name(name);
Query OK, 5 rows affected (0.23 sec)
Records: 5 Duplicates: 0 Warnings: 0 |
表20-12 InnoDB存儲(chǔ)引擎的表使用不同索引的阻塞例子
· session_1 | · session_2 |
mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) | mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) |
mysql> select * from tab_with_index where id = 1 for update; +------+------+ | id | name | +------+------+ | 1 | 1 | | 1 | 4 | +------+------+ 2 rows in set (0.00 sec) | |
| Session_2使用name的索引訪問記錄，因?yàn)橛涗洓]有被索引，所以可以獲得鎖： mysql> select * from tab_with_index where name = '2' for update; +------+------+ | id | name | +------+------+ | 2 | 2 | +------+------+ 1 row in set (0.00 sec) |
| 由于訪問的記錄已經(jīng)被session_1鎖定，所以等待獲得鎖。： mysql> select * from tab_with_index where name = '4' for update; |
（4）即便在條件中使用了索引字段，但是否使用索引來(lái)檢索數(shù)據(jù)是由MySQL通過判斷不同執(zhí)行計(jì)劃的代價(jià)來(lái)決定的，如果MySQL認(rèn)為全表掃描效率更高，比如對(duì)一些很小的表，它就不會(huì)使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖沖突時(shí)，別忘了檢查SQL的執(zhí)行計(jì)劃，以確認(rèn)是否真正使用了索引。關(guān)于MySQL在什么情況下不使用索引的詳細(xì)討論，參見本章“索引問題”一節(jié)的介紹。
在下面的例子中，檢索值的數(shù)據(jù)類型與索引字段不同，雖然MySQL能夠進(jìn)行數(shù)據(jù)類型轉(zhuǎn)換，但卻不會(huì)使用索引，從而導(dǎo)致InnoDB使用表鎖。通過用explain檢查兩條SQL的執(zhí)行計(jì)劃，我們可以清楚地看到了這一點(diǎn)。
例子中tab_with_index表的name字段有索引，但是name字段是varchar類型的，如果where條件中不是和varchar類型進(jìn)行比較，則會(huì)對(duì)name進(jìn)行類型轉(zhuǎn)換，而執(zhí)行的全表掃描。
mysql> alter table tab_no_index add index name(name);
Query OK, 4 rows affected (8.06 sec)
Records: 4 Duplicates: 0 Warnings: 0 mysql> explain select * from tab_with_index where name = 1 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tab_with_index
type: ALL
possible_keys: name
key: NULL
key_len: NULL
ref: NULL
rows: 4
Extra: Using where
1 row in set (0.00 sec)
mysql> explain select * from tab_with_index where name = '1' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tab_with_index
type: ref
possible_keys: name
key: name
key_len: 23
ref: const
rows: 1
Extra: Using where
1 row in set (0.00 sec) |