update卡住且状态为updating，是因为innodb未走有效索引导致临键锁扩大范围；select ... for update锁范围由隔离级别、索引类型和查询条件共同决定；insert因间隙锁可能引发死锁；验证锁需查performance_schema.data_locks等视图。
为什么 UPDATE 语句会卡住，且 SHOW PROCESSLIST 看到状态是 Updating？
因为 InnoDB 在执行 UPDATE 时默认加行级 X（排他）锁，但锁的粒度和范围不只看 WHERE 条件是否命中主键——它取决于执行计划是否能用上唯一索引。
常见错误现象：UPDATE users SET status = 1 WHERE id = 100 卡住，而另一事务正执行 SELECT * FROM users WHERE name = 'alice' FOR UPDATE（name 无索引），导致全表扫描并锁住所有行。
- 必须确认 WHERE 条件列有**有效索引**（非失效、非隐式转换），否则退化为临键锁（Next-Key Lock）覆盖整个索引范围
-
EXPLAIN的key和rows字段比 SQL 写法更可信：若rows远大于预期，大概率锁了不该锁的行 - 唯一索引等值查询（如
WHERE id = ?）只锁单行；范围查询（如WHERE id > 100）会锁住间隙，防止幻读
SELECT ... FOR UPDATE 为什么有时锁表，有时只锁几行？
锁的范围由「隔离级别 + 索引类型 + 查询条件」共同决定，不是语法本身说了算。在 REPEATABLE READ 下，InnoDB 默认用 Next-Key Lock，即「记录锁 + 间隙锁」组合。
使用场景：秒杀扣减库存、订单生成前校验余额，都依赖它阻止并发插入/更新同一批数据。
- 没走索引 → 全表扫描 → 所有索引项+间隙都被锁，表现像锁表
- 走了非唯一索引 → 锁住匹配记录 + 对应间隙，但可能比主键锁更多行（因辅助索引 B+ 树叶子节点存的是主键值，需回表，锁范围扩大）
- 用了
SELECT ... FOR UPDATE NOWAIT可避免阻塞，直接报错Lock wait timeout exceeded，适合高并发快速失败场景
INSERT 为什么会触发死锁，且错误信息里出现 waited for X lock on RECORD？
INSERT 不仅锁自己要插的记录，还会锁「插入位置的间隙」——这是为了防止幻读。当两个事务试图插入同一间隙内的不同记录时，就可能互相等待对方释放间隙锁。
典型死锁链：T1 插入 (5, 'a') → 锁间隙 (3,7)；T2 插入 (6, 'b') → 也需间隙 (3,7)，同时 T1 又想插 (6, 'c') → 循环等待。
- 间隙锁（Gap Lock）不可被
SELECT ... LOCK IN SHARE MODE阻止，只对 INSERT/UPDATE/DELETE 生效 - 将隔离级别降为
READ COMMITTED可禁用间隙锁（但失去幻读防护），适用于日志类写多读少场景 - 批量插入时尽量按主键顺序进行，减少间隙重叠；避免在高频并发点用 UUID 作主键（随机插入加剧间隙冲突）
如何验证某条 SQL 实际加了什么锁？
不能靠猜，得查 INFORMATION_SCHEMA.INNODB_TRX、INNODB_LOCKS（MySQL 8.0+ 已移除）和 INNODB_LOCK_WAITS，但更直接的是用 sys.innodb_lock_waits 视图或分析 SHOW ENGINE INNODB STATUS 输出里的 LATEST DETECTED DEADLOCK 或 TRANSACTIONS 部分。
关键字段：LOCK_TRX_ID 对应事务 ID，LOCK_MODE 显示 S/X/REC_NOT_GAP/GAP，LOCK_DATA 是被锁记录的主键值或间隙边界。
-
SELECT * FROM performance_schema.data_locks（MySQL 8.0+）可实时看到每个事务持有的锁，LOCK_TYPE为RECORD或TABLE，LOCK_INDEX指明哪个索引 - 测试时务必在真实事务中执行（BEGIN 后），自动提交模式下锁瞬间释放，查不到
- 注意
data_locks中的LOCK_DATA是字符串形式，若显示supremum pseudo-record，说明锁的是索引末尾间隙
锁的边界永远比看起来更模糊——同一句 SQL，在不同索引、不同数据分布、不同隔离级别下，锁的行数和类型可能完全不同。最危险的不是锁不住，而是你以为只锁了一行，其实锁住了整个范围。
