InnoDB对WHERE a=1 AND b>100且索引为(a,b)的UPDATE语句，会对扫描路径上所有索引项加next-key lock，包括(a=1,b=120)、(a=1,b=180)、(a=1,b=250)及其对应间隙，即使仅b=180和250满足条件；因B+树顺序遍历，无法跳过中间节点。
WHERE 条件用到联合索引的前缀等值 + 后缀范围时，锁哪些索引记录？
当 UPDATE 使用形如 WHERE a = 1 AND b > 100 的条件，且存在联合索引 INDEX (a, b) 时，InnoDB 不会只锁满足条件的行，而是按扫描路径对**所有被扫描到的索引记录**加 next-key lock（临键锁）。关键在于：扫描范围由最左前缀决定，而锁范围由实际遍历的索引项决定。
例如表中 a = 1 的数据对应 b 值为 [50, 120, 180, 250]，那么执行 UPDATE ... WHERE a = 1 AND b > 100 会从 (a=1, b=120) 开始向右扫描，直到 b 超出当前索引页或满足终止条件。此时被加锁的索引记录至少包括：
-
(a=1, b=120)→ 加 next-key lock，覆盖区间(b=50, b=120] -
(a=1, b=180)→ 加 next-key lock，覆盖区间(b=120, b=180] -
(a=1, b=250)→ 加 next-key lock，覆盖区间(b=180, b=250] - 如果
b=250是该a=1分组的最后一条，则还会在(a=1, b=250)之后的间隙（比如(250, +∞)）加 gap lock
注意：即使 b > 100 实际只命中 b=180 和 b=250 两行，b=120 这条也会被扫描到并加锁——因为 B+ 树是顺序遍历，无法跳过中间节点。
为什么 INDEX (b, a) 会导致全表扫描式加锁？
联合索引顺序不匹配查询模式时，优化器大概率放弃使用该索引。例如条件是 a = 1 AND b > 100，但索引是 INDEX (b, a)，则 a = 1 不是最左前缀，无法高效定位起始点，优化器可能回退到全表扫描（type = ALL），进而对每条聚簇索引记录都加锁。
此时锁行为等效于无索引更新：所有被扫描的主键记录都被加上 record lock + gap lock，实际效果接近表锁。可通过 EXPLAIN FORMAT=JSON 确认 key 字段是否为 null 或非预期索引名。
常见误判点：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 建了索引 ≠ 查询能用上 → 必须满足最左前缀，且无隐式类型转换（如
a = '1'对INT列） - 即使
EXPLAIN显示用了索引，若rows值极大（如 10 万）、filtered极低（如 1%），说明扫描范围过大，锁范围也大 -
FORCE INDEX (b, a)不能修复逻辑错误，只会让执行计划强制走一个低效路径，锁得更广
唯一联合索引（含主键）对范围条件是否退化为记录锁？
不会。唯一性只影响等值查询（=）时的锁类型：对 PRIMARY KEY 或 UNIQUE KEY 的等值条件，InnoDB 在 RR 隔离级别下退化为纯 record lock，不加 gap lock。但一旦出现范围条件（>、、<code>BETWEEN、LIKE 'abc%'），即使索引唯一，也会启用 next-key lock。
例如 INDEX (a, b) UNIQUE，执行 UPDATE ... WHERE a = 1 AND b > 100，仍会对扫描到的每个 (a=1, b=x) 加 next-key lock，包括其后的间隙。这是因为范围查询天然存在“幻读风险”，InnoDB 必须封锁间隙来保证可重复读语义。
验证方式：
- 查
information_schema.INNODB_TRX确认事务状态和运行时间 - 查
performance_schema.data_locks（MySQL 8.0+）看具体锁类型：LOCK_MODE = X, LOCK_TYPE = RECORD, LOCK_DATA = '1, 120'表示 record lock；LOCK_MODE = X, LOCK_TYPE = RECORD, LOCK_DATA = '1, 120', LOCK_GAP = TRUE表示 gap lock；两者共存即 next-key lock
如何最小化范围更新的锁影响？
核心思路是收窄扫描范围，而非单纯减少更新行数。扫描越少，锁越少，死锁概率越低。
实操建议：
- 把高频范围条件字段尽量放在联合索引最左位，例如常查
a = ? AND b > ?，就建INDEX (a, b, c)，别建(b, a) - 避免在范围条件后还跟其他等值条件，如
WHERE a = 1 AND b > 100 AND c = 'x'——c = 'x'无法用于索引过滤，只能在引擎层做 post-filter，但锁已加在所有扫描记录上 - 用分页更新代替单次大范围更新：加
LIMIT 1000，配合WHERE id > last_id游标推进，每次只锁少量记录 - 确认隔离级别必要性：若业务允许读已提交（
READ COMMITTED），则范围查询默认不加 gap lock，仅锁匹配行（record lock），但需评估幻读容忍度
真正难处理的不是“锁了哪些”，而是“为什么扫了这些”——索引设计、查询写法、参数类型三者稍有错位，就会让锁范围指数级扩大。线上遇到慢更新阻塞，第一反应不该是 kill 线程，而是立刻查 EXPLAIN 和 data_locks，定位扫描起点和终点。
