分页更新触发间隙锁的根本原因是where条件未走索引或扫描范围过大，而非limit本身；innodb在rr级别下对扫描路径上的索引间隙加next-key lock，实际锁定范围远超更新行数，需通过explain验证执行计划。
为什么分页更新会触发间隙锁
分页更新（比如 LIMIT + OFFSET）在 REPEATABLE READ 隔离级别下极易触发间隙锁，根本原因不是“用了 LIMIT”，而是 WHERE 条件没走索引或扫描范围过大。例如：UPDATE t SET status=1 WHERE created_at —— 若 <code>created_at 无索引，InnoDB 会全表扫描并为整个扫描区间加间隙锁；即使有索引，若该字段值大量重复或时间范围太宽（如覆盖几百万行），也会锁住远超实际更新行数的间隙。
用主键游标替代 OFFSET 分页
这是最直接有效的规避方式：放弃基于偏移量的分页逻辑，改用主键（或带唯一索引的字段）作为游标推进。每次只查、只更新一段连续主键区间，确保每次扫描范围可控且索引高效命中。
- 错误写法：
UPDATE t SET x=1 WHERE status=0 LIMIT 5000—— 每次都从头扫，锁范围不可控，事务越跑越慢 - 正确写法：
UPDATE t SET x=1 WHERE id > 10000 AND id —— 明确边界，仅锁这 5000 个主键值之间的间隙（实际只锁涉及的索引节点） - 后续推进靠上一批最大
id值：SELECT MAX(id) FROM t WHERE id > 10000 AND id ，下一轮用该值作为新起点 - 务必避免在 WHERE 中混用函数或表达式（如
DATE(created_at)），否则索引失效，直接退化为全表间隙锁
隔离级别与锁行为的关系不能忽略
REPEATABLE READ 是 MySQL 默认隔离级别，也是间隙锁最活跃的环境；而 READ COMMITTED 下间隙锁基本不启用（仅在某些外键或唯一约束检查时保留），对分页更新类操作更友好。
- 确认当前会话级别：
SELECT @@transaction_isolation - 临时切换（仅限非核心业务或维护窗口）：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED - 注意副作用：降级后可能产生不可重复读，但对“批量状态翻转”类更新（如标记已处理）通常可接受
- 不要全局修改
innodb_default_isolation，影响面太大；优先在应用层按需设置会话级隔离
UPDATE 语句本身就能避免部分间隙锁陷阱
很多人误以为只有 SELECT ... FOR UPDATE 才会加间隙锁，其实 UPDATE 和 DELETE 在范围条件匹配时同样会触发——但它们的锁行为更“务实”：只锁真正需要修改的记录及其间隙，且不保留共享锁等待队列。
- 别为了“先查再更”写两步：
SELECT id FROM t WHERE ... FOR UPDATE→UPDATE t SET ... WHERE id IN (...)，这会额外持锁、放大间隙范围 - 直接一条
UPDATE完成：MySQL 会在执行时自动评估并加锁，比手动拆解更紧凑 - 如果必须分批，用
WHERE id BETWEEN ? AND ?而非WHERE id > ? LIMIT N，后者在高并发下易因主键跳跃导致漏更新或重复更新 - 记得加
ORDER BY id（虽然UPDATE不显式支持，但 WHERE 中的主键范围天然有序）
EXPLAIN 看执行计划，确认 key、rows、Extra 三项是否符合预期，比调参更管用。
