InnoDB 引擎支持行级锁，主要包括 Record Lock、Gap Lock 和 Next-Key Lock。锁定读通过 SELECT ... FOR UPDATE 实现，用于解决快照读在并发场景下的超卖等问题。加锁对象为索引，Next-Key Lock 在特定场景下会退化为记录锁或间隙锁。唯一索引等值查询存在时退化记录锁，不存在时退化间隙锁；非唯一索引范围查询通常保持 Next-Key Lock。全表扫描会导致锁全表。死锁可通过设置超时时间或开启死锁检测解决，业务上建议利用唯一索引避免幂等性校验冲突。
InnoDB 引擎是支持行级锁的，而 MyISAM 引擎并不支持行级锁。
顾名思义，行锁就是针对数据表中行记录的锁。这很好理解，比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。
前面也提到，普通的 select 语句是不会对记录加锁的，因为它属于快照读。如果要在查询时对记录加行锁，可以使用下面这两个方式，这种查询会加锁的语句称为锁定读。
-- 对读取的记录加共享锁
SELECT ... LOCK IN SHARE MODE;
-- 对读取的记录加独占锁
SELECT ... ;
Record Lock 称为记录锁，锁住的是一条记录。而且记录锁是有 S 锁和 X 锁之分的：
举个例子，当一个事务执行了下面这条语句：
BEGIN;
SELECT * FROM t_test WHERE id = 1 FOR UPDATE;
就是对 t_test 表中主键 id 为 1 的这条记录加上 X 型的记录锁，这样其他事务就无法对这条记录进行修改了。
当事务执行 commit 后，事务过程中生成的锁都会被释放。
Gap Lock 称为间隙锁，存在于可重复读隔离级别和串行化隔离级别，目的是为了解决可重复读隔离级别下幻读的现象。
假设，表中有一个范围 id 为（3，5）间隙锁，那么其他事务就无法插入 id = 4 这条记录了，这样就有效的防止幻读现象的发生。
Next-Key Lock 称为临键锁，是 Record Lock + Gap Lock 的组合，锁定一个范围，并且锁定记录本身。
假设，表中有一个范围 id 为（3，5] 的 next-key lock，那么其他事务即不能插入 id = 4 记录，也不能修改 id = 5 这条记录。
所以，next-key lock 即能保护该记录，又能阻止其他事务将新纪录插入到被保护记录前面的间隙中。
next-key lock 是包含间隙锁 + 记录锁的，如果一个事务获取了 X 型的 next-key lock，那么另外一个事务在获取相同范围的 X 型的 next-key lock 时，是会被阻塞的。
可以解决'快照读'在特定场景下的不足
在 MySQL 的默认隔离级别'可重复读'下，普通的 SELECT 语句是'快照读'。它基于 MVCC 读取一个历史快照，不会加锁。这虽然保证了高并发下的读取性能，但在某些业务场景下会产生问题。
经典场景：库存扣减
假设商品 A 的库存为 1。
SELECT stock FROM products WHERE id = 1;（返回 stock=1）SELECT stock FROM products WHERE id = 1;（返回 stock=1）UPDATE products SET stock = stock - 1 WHERE id = 1并提交。UPDATE products SET stock = stock - 1 WHERE id = 1并提交。最终结果是库存变成了 -1，这就是典型的'超卖'问题。
使用 SELECT … FOR UPDATE 解决：
SELECT stock FROM products WHERE id = 1 FOR UPDATE;（对 id=1 的记录加排他锁）加锁的对象是索引，加锁的基本单位是 next-key lock。
但是，next-key lock 在一些场景下会退化成记录锁或间隙锁。
那到底是什么场景呢？总结一句，在能使用记录锁或者间隙锁就能避免幻读现象的场景下，next-key lock 就会退化成记录锁或间隙锁。
这次会以下面这个表结构来进行实验说明：
CREATE TABLE `user` (
`id` bigint NOT NULL AUTO_INCREMENT,
`name` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL,
`age` int NOT NULL,
PRIMARY KEY (`id`),
KEY `index_age` (`age`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
其中，id 是主键索引（唯一索引），age 是普通索引（非唯一索引），name 是普通的列。
表中的有这些行记录：
我本篇文章的「唯一索引」是用「主键索引」作为案例说明的，加锁只加在主键索引项上。
然后，很多同学误以为如果是二级索引的「唯一索引」，加锁也是只加在二级索引项上。
其实这是不对的，所以这里特此说明下，如果是用二级索引（不管是不是非唯一索引，还是唯一索引）进行锁定读查询的时候，除了会对二级索引项加行级锁（如果是唯一索引的二级索引，加锁规则和主键索引的案例相同），而且还会对查询到的记录的主键索引项上加「记录锁」。
在文章的「非唯一索引」的案例中，我就是用二级索引作为例子，在后面的章节我有说明，对二级索引进行锁定读查询的时候，因为存在两个索引（二级索引和主键索引），所以两个索引都会加锁。
当我们用唯一索引进行等值查询的时候，查询的记录存不存在，加锁的规则也会不同：
BEGIN;
SELECT * FROM user WHERE id = 1 FOR UPDATE;
接下来，如果有其他事务，对 id 为 1 的记录进行更新或者删除操作的话，这些操作都会被阻塞，因为更新或者删除操作也会对记录加 X 型的记录锁，而 X 锁和 X 锁之间是互斥关系。
BEGIN;
SELECT * FROM user WHERE id = 2 FOR UPDATE;
此时事务 A 在 id = 5 记录的主键索引上加的是间隙锁，锁住的范围是 (1, 5)。
假设事务 A 执行了这条范围查询语句：
BEGIN;
SELECT * FROM user WHERE id > 15 FOR UPDATE;
假设事务 A 执行了这条范围查询语句：
BEGIN;
SELECT * FROM user WHERE id >= 15 FOR UPDATE;
假设事务 A 执行了这条范围查询语句，注意查询条件值的记录（id 为 6）并不存在于表中。
BEGIN;
SELECT * FROM user WHERE id < 6 FOR UPDATE;
读者提问：请教一个问题 在看 mysql 加行级锁中 select * from user where id<6 for update; 为什么 id(5,10) 要加间隙锁呢？不加 也不会发生幻读吧？
回答：第三个间隙锁是加在 id=10 索引上的，这个例子不太好说明，如果是 id<7，id=10 索引不加间隙锁的话，中途插入一个 6，就发生幻读了
假设事务 A 执行了这条范围查询语句，注意查询条件值的记录（id 为 5）存在于表中。
BEGIN;
SELECT * FROM user WHERE id <= 5 FOR UPDATE;
当我们用非唯一索引进行等值查询的时候，因为存在两个索引，一个是主键索引，一个是非唯一索引（二级索引），所以在加锁时，同时会对这两个索引都加锁，但是对主键索引加锁的时候，只有满足查询条件的记录才会对它们的主键索引加锁。
先说结论：
假设事务 A 对非唯一索引（age）进行了等值查询，且表中不存在 age = 25 的记录。
BEGIN;
SELECT * FROM user WHERE age = 25 FOR UPDATE;
假设事务 A 对非唯一索引（age）进行了等值查询，且表中存在 age = 22 的记录。
BEGIN;
SELECT * FROM user WHERE age = 22 FOR UPDATE;
非唯一索引和主键索引的范围查询的加锁也有所不同，不同之处在于非唯一索引范围查询，索引的 next-key lock 不会有退化为间隙锁和记录锁的情况，都是加 next-key 锁。
就带大家简单分析一下，事务 A 的这条范围查询语句：
BEGIN;
SELECT * FROM user WHERE age >= 22 FOR UPDATE;
在 age >= 22 的范围查询中，明明查询 age = 22 的记录存在并且属于等值查询，为什么不会像唯一索引那样，将 age = 22 记录的二级索引上的 next-key 锁退化为记录锁？
因为 age 字段是非唯一索引，不具有唯一性，所以如果只加记录锁（记录锁无法防止插入，只能防止删除或者修改），就会导致其他事务插入一条 age = 22 的记录，这样前后两次查询的结果集就不相同了，出现了幻读现象。
读者问题：这里的查询条件如果是 age <= 22，验证了一下确实都是临键锁，不过感觉 age=39 那里加一个间隙锁就可以避免幻读了，为什么 age=39 也要加临键锁额外的把 39 也锁住了。
回答：这里属于能优化，但是 mysql 没有做这方面的优化，具体原因未知，官方文档也没解释，大概率是作者忘记了😂
当前读查询语句没有使用索引列作为查询条件，或者查询语句没有走索引查询，导致扫描是全表扫描。那么，每一条记录的索引上都会加 next-key 锁，这样就相当于锁住的全表，这时如果其他事务对该表进行增、删、改操作的时候，都会被阻塞。
不只是当前读查询语句不加索引才会导致这种情况，update 和 delete 语句如果查询条件不加索引，那么由于扫描的方式是全表扫描，于是就会对每一条记录的索引上都会加 next-key 锁，这样就相当于锁住的全表
问题：为什么 select…for update/ update / delete 这些语句的查询语句没有走索引就会对每一条记录的索引上加 next-key 锁（锁全表）呢？
答案：是为了防止在事务执行期间，其他事务修改或删除某一条记录，或者在其前后插入新记录，从而出现了不可重复读和幻读的问题。
我建了一张订单表，其中 id 字段为主键索引，order_no 字段普通索引，也就是非唯一索引：
CREATE TABLE `t_order` (
`id` int NOT NULL AUTO_INCREMENT,
`order_no` int DEFAULT NULL,
`create_date` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `index_order` (`order_no`) USING BTREE
) ENGINE=InnoDB;
然后，先 t_order 表里现在已经有了 6 条记录：
假设这时有两事务，一个事务要插入订单 1007，另外一个事务要插入订单 1008，因为需要对订单做幂等性校验，所以两个事务先要查询该订单是否存在，不存在才插入记录，过程如下：
对于 A 事务而言，因为表中最大记录是 1006，所以会对 (1006, +∞] 加 next-key 锁
对于 B 事务而言，也是会对 (1006, +∞] 加 next-key 锁
两个事务在插入的时候都在等待对方事务的间隙锁释放，于是就造成了循环等待，导致死锁。
死锁的四个必要条件：互斥、占有且等待、不可强占用、循环等待。只要系统发生死锁，这些条件必然成立，但是只要破坏任意一个条件就死锁就不会成立。
在数据库层面，有两种策略通过「打破循环等待条件」来解除死锁状态：
当发生超时后，就出现下面这个提示：
当检测到死锁后，就会出现下面这个提示：
上面这个两种策略是「当有死锁发生时」的避免方式。
我们可以回归业务的角度来预防死锁，对订单做幂等性校验的目的是为了保证不会出现重复的订单，那我们可以直接将 order_no 字段设置为唯一索引列，利用它的唯一性来保证订单表不会出现重复的订单，不过有一点不好的地方就是在我们插入一个已经存在的订单记录时就会抛出异常。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
在线格式化和美化您的 SQL 查询（它支持各种 SQL 方言）。 在线工具，SQL 美化和格式化在线工具，online
解析 INSERT 等受限 SQL，导出为 CSV、JSON、XML、YAML、HTML 表格（见页内语法说明）。 在线工具，SQL转CSV/JSON/XML在线工具，online
CSV 与 JSON/XML/HTML/TSV/SQL 等互转，单页多 Tab。 在线工具，CSV 工具包在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online