应将select for update推迟至update前一刻执行，仅在真正更新前加锁，避免提前持锁导致阻塞；update必须使用主键或唯一索引条件，禁止函数操作或非索引字段，防止锁范围扩大。
SELECT FOR UPDATE 别急着加，先查后锁
很多业务写法是：事务一开启就 SELECT ... FOR UPDATE，然后做校验、调外部接口、解析 JSON，最后才 UPDATE。这等于从第一行代码开始就锁住数据，后续所有耗时操作都在持锁状态下进行。
真正该做的是把加锁动作“往后挪”——只在要更新前一刻才加锁。比如库存扣减场景：
- 先
SELECT stock FROM item WHERE id = 123（不加锁，快照读） - 校验库存是否充足、生成订单、调支付网关
- 最后一步：
UPDATE item SET stock = stock - 1 WHERE id = 123 AND stock >= 1
这样锁只在最后一行 SQL 执行期间持有，通常几毫秒就释放，而不是卡住整个业务流程。
UPDATE 必须带确定主键或唯一索引条件
用非索引字段更新，InnoDB 会全表扫描并给每一行加 X 锁；用非唯一二级索引，还会触发回表 + 间隙锁，锁范围远超预期。
典型反例：UPDATE user SET status = 1 WHERE name = 'alice' —— 如果 name 没索引，就是隐式表锁；即使有非唯一索引，也可能锁住 name = 'alice' 对应的所有主键行及间隙。
正确做法：
- 优先走主键：
UPDATE user SET status = 1 WHERE id = 1001 - 若必须按业务字段更新，确保该字段有唯一索引：
ALTER TABLE user ADD UNIQUE INDEX idx_name (name) - 避免在 WHERE 中对字段做函数处理，如
WHERE DATE(created_at) = '2026-06-13'会让索引失效
批量操作必须分片，不能一把梭
UPDATE order SET status = 2 WHERE created_at 这类语句在 RR 隔离级别下可能锁住成千上万行和间隙，其他事务一碰就 <code>Lock wait timeout exceeded。
拆分的核心是“按主键范围切片 + 每批独立提交”：
- 先查出待更新的主键范围：
SELECT MIN(id), MAX(id) FROM order WHERE created_at - 再按每 50–100 行一批循环执行：
UPDATE order SET status = 2 WHERE id BETWEEN 10000 AND 10099 AND created_at - 每批执行完立刻
COMMIT，释放该批次所有锁
别用 IN 列表拼大集合，MySQL 对 IN (1,2,...,1000) 的优化有限，仍可能锁全范围。
ORDER BY + LIMIT + FOR UPDATE 容易锁过宽
看似只想要一行，但 SELECT * FROM t WHERE id > 100 ORDER BY id LIMIT 1 FOR UPDATE 在 RR 下会锁住 id > 100 的整个间隙，防止幻读——哪怕表里只有 id=101 和 id=200 两行，中间所有空隙都被锁死。
更安全的写法是先用无锁查询拿到目标主键，再精确更新：
-
SELECT id FROM t WHERE id > 100 ORDER BY id LIMIT 1（普通 SELECT） -
SELECT * FROM t WHERE id = ? FOR UPDATE（只锁这一行）
如果业务允许，直接改用 READ COMMITTED 隔离级别也能让这类语句只锁命中行，不锁间隙——但得确认业务能接受不可重复读。
锁范围和持锁时间从来不是数据库配置能一键解决的，它直接取决于你写的每一条 SQL 怎么定位数据、什么时候加锁、锁多大一片。最容易被忽略的，其实是那些“看起来只影响一行”的语句，在没索引或用了模糊条件时，实际锁住的是整张表。
