聚簇索引更新易触发行锁升级为间隙锁，因RR级别下非唯一条件（如WHERE status='pending'）会加Next-Key Lock（记录锁+间隙锁），防止幻读；无索引时全表扫描则对每行加锁，进一步扩大锁定范围。
聚簇索引更新为什么容易触发行锁升级为间隙锁？
因为聚簇索引的叶子节点直接存储整行数据，InnoDB 在执行 UPDATE 或 DELETE 时，不仅要锁定目标记录本身（行锁），还会根据当前事务隔离级别和 WHERE 条件判断是否需要加间隙锁（Gap Lock）来防止幻读。尤其是使用非唯一条件（如 WHERE status = 'pending'）更新时，InnoDB 会扫描并锁定匹配范围内的所有间隙——哪怕这些位置当前没有数据。
常见错误现象：UPDATE orders SET paid = 1 WHERE user_id = 123 在 user_id 上无索引时，会触发全表扫描+全表行锁；即使有索引，若该列不是主键，也仍需先走二级索引查主键、再回表更新，中间可能被其他事务阻塞在二级索引或聚簇索引两层。
- 自增主键更新最轻量：只锁单行，不涉及间隙判断（除非用范围条件）
- UUID 主键更新代价高：B+树插入/移动频繁，页分裂导致锁持有时间变长，易引发死锁
- 显式
SELECT ... FOR UPDATE加锁顺序必须与后续UPDATE一致，否则可能因加锁顺序不同触发死锁
辅助索引更新为何必然伴随“两次加锁”？
辅助索引（二级索引）本身不存数据，只存索引列值 + 对应主键值。所以任何对辅助索引字段的 UPDATE，InnoDB 必须做两件事：先更新辅助索引 B+ 树的叶子节点（锁该二级索引记录），再根据它保存的主键去聚簇索引里定位并更新真实数据行（锁对应主键记录）。这天然构成两次独立的加锁动作。
使用场景举例：UPDATE users SET email = 'new@x.com' WHERE username = 'alice'，假设 username 上建了辅助索引 idx_username：
- 第一步：在
idx_username中定位到'alice'对应的主键id=456，对该二级索引项加 X 锁 - 第二步：在聚簇索引中查找
id=456的数据页，对该行加 X 锁，并实际修改email字段 - 如果
email列也被某个辅助索引覆盖（比如idx_email），那还要第三次加锁更新那个索引项
性能影响明显：每多一个辅助索引，UPDATE 就多一次 B+ 树遍历和一次加锁操作，写放大严重。
什么情况下辅助索引更新会意外锁住不相关的主键行？
当辅助索引列存在重复值，而更新语句又没精确命中唯一值时，InnoDB 为了保证一致性，可能扩大锁范围。例如表 logs 有辅助索引 idx_type_time（type, created_at），执行 UPDATE logs SET processed = 1 WHERE type = 'error' —— 这个条件无法利用索引的全部前缀，InnoDB 可能扫完整个 type='error' 的索引段，并对每个匹配项对应的主键都加锁，哪怕你只打算改其中几条。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
容易踩的坑：
-
UPDATE ... WHERE条件未覆盖辅助索引最左前缀，会导致索引失效，退化为扫描+锁全量匹配行 - 辅助索引字段被更新（如
UPDATE t SET name = 'x' WHERE name = 'y'），该索引项本身要重写，同时触发回表，双重开销 - 大批量更新时，建议分批次 + 按主键排序执行，避免长时间持有二级索引锁阻塞其他查询
如何验证某次 UPDATE 实际锁了哪些索引？
最直接的方式是查 INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS，但更实用的是开启监控：
- 执行
SET SESSION innodb_status_output_locks = ON - 运行疑似阻塞的
UPDATE（最好在低峰期） - 立即执行
SHOW ENGINE INNODB STATUS\G，在TRANSACTIONS部分找当前事务的lock_structs，里面会明确列出锁在哪个索引、哪条记录（如index `PRIMARY` of table `test`.`t` trx id 12345 lock_mode X locks rec but not gap）
注意：锁信息是瞬态的，SHOW ENGINE INNODB STATUS 只保留最近一次死锁或最近几秒的活跃锁快照，不能事后回溯。真正压测时建议配合 performance_schema.data_locks 表实时采集。
复杂点在于，同一个 UPDATE 可能在不同隔离级别下锁不同的索引层级，甚至同一语句在有无索引、索引是否覆盖、是否触发唯一约束检查等条件下，锁行为都可能完全不同——不能只看 SQL 文本，得结合执行计划和实际锁日志交叉验证。
