MySQL 事务中哪些语句会触发行锁？
不是所有
UPDATE或
SELECT ... FOR UPDATE都一定加行锁，关键看是否命中索引。InnoDB 只对通过**索引条件扫描到的记录**加行级锁；若
WHERE条件未命中任何索引（或走了全表扫描），就会升级为表锁（实际是每行都加锁，效果等同于锁全表）。
常见误判场景：
UPDATE users SET status = 1 WHERE name = 'alice'—— 若
name列无索引，将锁住所有行
SELECT * FROM orders WHERE id > 100 FOR UPDATE—— 若
id是主键，只锁满足条件的行；但若
id是普通索引且
id > 100范围过大，可能触发间隙锁（Gap Lock）
SELECT ... LOCK IN SHARE MODE和
FOR UPDATE行为一致，只是锁类型不同（S 锁 vs X 锁）
为什么 SELECT ... FOR UPDATE
有时不阻塞，有时死锁？
是否阻塞取决于目标行当前是否被其他事务持有冲突锁（如另一事务已对该行加了 X 锁），以及隔离级别下是否启用间隙锁。在
REPEATABLE READ下，InnoDB 默认启用间隙锁来防止幻读，这会让看似“不相干”的范围查询互相影响。
典型死锁链路：
事务 A：SELECT * FROM t WHERE id = 5 FOR UPDATE; 事务 B：SELECT * FROM t WHERE id = 10 FOR UPDATE; 事务 A：UPDATE t SET v = 1 WHERE id = 10; -- 等待 B 释放 事务 B：UPDATE t SET v = 2 WHERE id = 5; -- 等待 A 释放 → 死锁
更隐蔽的是间隙锁参与的死锁，例如：
A 执行SELECT * FROM t WHERE age BETWEEN 20 AND 30 FOR UPDATE→ 锁住 (20,30) 间隙 + 匹配行 B 同时执行
INSERT INTO t (age) VALUES (25)→ 等待间隙锁释放 若 B 也先锁了某行再反向请求 A 的间隙，则触发死锁检测
SHOW ENGINE INNODB STATUS
中怎么看锁等待？
这是定位锁问题最直接的手段。执行后重点关注
TRANSACTIONS部分里的
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:和
*** (2) HOLDS THE LOCK(S):两段。
关键字段含义：
lock_mode X locks rec but not gap：记录锁（仅锁已有数据行）
lock_mode X locks gap before rec：间隙锁（锁住前一个值到本行之间的空隙）
lock_mode X locks rec but not gap waiting：正在等待获取记录锁
lock_trx_id和
lock_row_id可关联到具体事务和行物理位置
注意：该命令输出是快照，不实时；且只显示最近一次死锁信息（在
LATEST DETECTED DEADLOCK段）。
如何避免长事务导致的锁等待堆积？
锁等待本身不可怕，可怕的是事务长时间不提交，把锁占着不动。常见诱因是应用层未正确控制事务边界，比如在事务中调用慢速外部 API、做大量计算、或使用了自动提交关闭但忘记
COMMIT的连接池配置。
实操建议：
在业务代码中显式控制BEGIN/
COMMIT/
ROLLBACK，避免依赖框架默认行为 设置
innodb_lock_wait_timeout（默认 50 秒），让等待过久的事务快速失败而非卡死 监控
information_schema.INNODB_TRX表，定期查
TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60的长事务 写操作尽量走主键或唯一索引，减少锁粒度；读多写少场景可考虑
READ COMMITTED隔离级别（禁用间隙锁）
间隙锁和锁升级逻辑在不同版本 MySQL 中有差异，尤其 8.0 对唯一索引的等值查询做了优化（可能不加间隙锁），实际排查一定要结合自己的 MySQL 版本和表结构确认。
