InnoDB仅对索引条件扫描到的记录加行锁；未命中索引则每行加锁等效表锁。SELECT ... FOR UPDATE是否阻塞取决于锁冲突与隔离级别，REPEATABLE READ下间隙锁易引发死锁。
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 版本和表结构确认。
