SQL悲观锁通过FOR UPDATE和FOR SHARE两种模式实现，前者用于独占式锁定，后者用于共享式锁定，二者的行锁范围由查询条件、索引情况共同决定，不当使用极易引发死锁。理解锁范围并制定预防规则是并发开发的核心环节。
一、FOR UPDATE 与 FOR SHARE 基础特性
FOR UPDATE会对查询到的行加排他锁，其他事务无法对这些行加任何锁，也不能修改、删除数据，适合需要更新数据的场景。FOR SHARE会对查询到的行加共享锁，其他事务可以加共享锁但不能加排他锁，适合需要读取数据且防止被修改的场景。
两种锁的加锁行为都遵循事务生命周期，只有事务提交或回滚后锁才会释放，未提交的事务会一直持有锁资源。
二、行锁范围的影响因素
2.1 索引对锁范围的影响
如果查询条件使用了唯一索引且命中唯一记录，悲观锁只会锁定该条记录；如果查询条件没有使用索引或者使用非唯一索引，数据库会进行全表扫描，此时会对所有扫描到的行加锁，甚至可能升级为表锁。
以下示例展示唯一索引下的加锁情况：
-- 假设user表id是唯一主键，存在id=1和id=2的记录 -- 事务1执行 START TRANSACTION; SELECT * FROM user WHERE id = 1 FOR UPDATE; -- 此时只会锁定id=1这一行，其他事务可以操作id=2的行 -- 事务2执行 START TRANSACTION; SELECT * FROM user WHERE id = 2 FOR UPDATE; -- 可以正常执行，不会阻塞
2.2 查询条件对锁范围的影响
范围查询（如<、>、BETWEEN）在未使用索引时会锁定所有符合条件的行，使用普通索引时会锁定索引覆盖的所有范围行，即使部分行最终不满足查询条件，也可能被锁定（间隙锁场景）。
示例展示范围查询的加锁效果：
-- 假设user表age字段有普通索引，存在age为18、20、22的记录 -- 事务1执行 START TRANSACTION; SELECT * FROM user WHERE age > 18 AND age < 22 FOR UPDATE; -- 此时会锁定age=20的行，同时可能锁定18到22之间的间隙，防止其他事务插入age=19、21的记录 -- 事务2执行 START TRANSACTION; INSERT INTO user (age) VALUES (19); -- 会被阻塞，直到事务1提交
三、死锁预防 checklist
结合悲观锁的特性，整理以下可落地的死锁预防规则：
- 所有使用FOR UPDATE、FOR SHARE的查询必须命中索引，优先使用唯一索引，避免全表扫描导致的锁范围扩大。
- 事务中加锁的顺序保持一致，多个事务操作多行数据时，按照相同的字段排序后依次加锁，避免交叉等待锁资源。
- 尽量缩小事务范围，加锁后尽快完成业务操作并提交事务，减少锁的持有时间。
- 避免长事务，对于耗时较长的业务逻辑，不要在事务中执行，防止锁长时间不释放。
- 对热点数据操作前先查询是否存在，避免无效加锁，同时可以设置锁等待超时时间，防止无限等待。
- 不要在事务中执行用户交互类的操作，避免事务挂起导致锁长期持有。
- 定期监控数据库的死锁日志，针对高频死锁场景调整加锁逻辑和索引设计。
四、常见误区说明
很多开发者认为FOR SHARE不会引发死锁，实际上如果两个事务分别对不同的行加了共享锁，之后又尝试对这些行加排他锁，同样会产生死锁。比如事务1对行A加FOR SHARE，事务2对行B加FOR SHARE，之后事务1尝试对行B加FOR UPDATE，事务2尝试对行A加FOR UPDATE，就会形成死锁。
另外，即使查询条件看起来只命中一行，如果没有使用索引，数据库依然可能锁定多行，因此索引设计是使用悲观锁的前提。
SQL_悲观锁FOR_UPDATEFOR_SHARE行锁范围死锁预防修改时间：2026-07-07 20:57:11