首先明确一个核心结论：MySQL UPDATE范围查询触发意向排他锁（IX）冲突的根本原因并非IX锁本身就具有阻塞能力——它实际上只是一种隐式持有的表级意图标记，本身不阻塞任何操作。然而，问题在于InnoDB在施加next-key锁的同时，会在表级别隐式持有IX锁；IX锁虽然不会与其他IX锁直接冲突，却可能与DDL操作（如ALTER TABLE）或表级X/S锁产生兼容性冲突。更常见的场景是，多个范围UPDATE操作交叉扫描同一索引区间，引发底层记录锁与间隙锁的激烈竞争。最终表现为“Waiting for table metadata lock”或“等待获取IX锁”等等待事件。

用主键分批 + 显式ORDER BY规避锁范围扩散

MySQL原生的UPDATE语句本身并不直接支持ORDER BY（8.0.19及以上版本仅在单表无JOIN场景下可用），因此无法通过SQL直接强制执行更新顺序。此时需要在应用层进行控制：

• 首先执行一条SELECT id FROM t WHERE status = 'pending' AND created_at >= '2026-06-01' ORDER BY id LIMIT 500，确保取出的ID按升序排列
• 获取结果后，显式调用.sort()进行一次排序（避免驱动或ORM自动重排导致顺序错乱）
• 拼接UPDATE t SET status = 'processing' WHERE id IN (101,102,105,...)，并确保IN列表中的ID顺序与排序后一致
• 每批完成后立即执行COMMIT，释放所有锁并断开事务上下文

这里有一个关键细节：每批步长不宜超过500，否则优化器可能放弃索引扫描。另外，切勿使用LIMIT代替主键过滤——全表扫描后再截断，仍然会锁定所有扫描过的间隙，这是最大的陷阱。

联合索引设计压缩next-key锁影响边界

如果业务需求必须按非主键字段进行范围更新，单列索引的效果往往十分有限。正确的方案是创建覆盖式联合索引，让InnoDB能够精准定位索引片段：

• 以status和created_at为例，可以建立INDEX idx_status_ctime_id (status, created_at, id)
• 查询条件必须严格遵循最左前缀匹配：WHERE status = 'pending' AND created_at BETWEEN '2026-06-01' AND '2026-06-07'
• 通过EXPLAIN查看执行计划，type应显示为range，key命中该联合索引，rows值合理（不应动辄几万行）

这样一来，锁只会落在(pending, '2026-06-01')到(pending, '2026-06-07')这个狭窄区间内，而不会覆盖整个created_at轴上的所有间隙，效果立竿见影。

READ COMMITTED隔离级别下间隙锁是否还生效

在READ COMMITTED隔离级别下，InnoDB不会添加任何间隙锁（Gap Lock）和临键锁（Next-Key Lock），仅对实际命中的记录施加记录锁（Record Lock）。这意味着：

• UPDATE t SET x=1 WHERE id > 100只锁定id=101、102等已存在的行，不会锁定(100,101)或(105,+∞)这些间隙
• 并发INSERT新id不再被阻塞，幻读可能发生，但写入吞吐量会有明显提升
• 需要确认业务是否能接受不可重复读——例如两次SELECT之间其他事务提交了新数据，第二次UPDATE可能基于旧快照工作

设置方式非常简单：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED；如需全局修改，需编辑my.cnf中的transaction_isolation并重启数据库。切勿轻信ORM的默认行为，某些框架（如旧版Django ORM）会静默维持RR隔离级别。

最后补充一点。真正令人困扰的并非IX锁本身，而是它与范围条件耦合后暴露出的隐式依赖关系。举例来说：当你按时间范围进行更新时，可能没有意识到这个范围在索引中对应了一大片物理上连续的页面，而此时另一个事务正在向同一页插入新记录——即使添加了索引，锁冲突依然会频繁发生。这才是问题的核心所在。