行锁仅在 InnoDB 引擎且索引命中时生效；否则退化为表锁，间隙锁在 RR 级别下还会锁索引间隙，事务提交前不释放锁。
行锁只在 InnoDB + 索引命中时才生效
MySQL 不是“一执行 UPDATE 就加行锁”，而是取决于存储引擎和查询条件是否能走索引。MyISAM 引擎压根不支持行锁，所有 DML 都是表锁；InnoDB 虽默认支持行锁，但一旦 WHERE 条件没命中索引（比如对无索引字段更新），就会退化为全表扫描 → 触发隐式表锁。
- ✅ 正确触发行锁：
UPDATE users SET status = 1 WHERE id = 1001;（
id是主键或唯一索引） - ❌ 退化为表锁：
UPDATE users SET status = 1 WHERE name = 'Alice';（
name字段无索引） - ⚠️ 注意：即使有索引，若优化器判断走索引成本高（如返回大量行），也可能放弃索引 → 同样触发表锁
SELECT FOR UPDATE 和 LOCK IN SHARE MODE 才显式加锁
普通 SELECT 在可重复读（RR）或读已提交（RC）隔离级别下，默认走 MVCC 快照读，** 完全不加锁 **。只有显式带上锁提示，才会真正申请行级排他锁或共享锁。
-
SELECT * FROM orders WHERE order_id = 123 FOR UPDATE;→ 加 X 锁（阻塞其他 X/S 锁） -
SELECT * FROM orders WHERE order_id = 123 LOCK IN SHARE MODE;→ 加 S 锁（允许多个 S 锁，但阻塞 X 锁） - ⚠️ 坑点：如果
WHERE条件没走索引，这两条语句也会锁整张表，不是只锁“看起来匹配的那几行”
间隙锁和临键锁：可重复读下的“隐形枷锁”
在默认隔离级别 REPEATABLE READ 下，InnoDB 不仅锁记录，还会锁住索引间隙（Gap Lock）甚至记录 + 间隙（Next-Key Lock）。这会导致看似无关的 INSERT 或 UPDATE 被阻塞。
- 例如：
SELECT * FROM users WHERE age BETWEEN 25 AND 35 FOR UPDATE;→ 实际会锁住
(20, 25]、(25, 35]、(35, 40)等多个间隙（取决于索引分布） - 插入
age = 28的新用户会被阻塞，哪怕原表里没有age = 28的记录 - ? 解法之一：临时降级到
READ COMMITTED（需权衡幻读风险），此时间隙锁被禁用，只保留记录锁
事务提交前不释放锁：两阶段锁协议的真实代价
InnoDB 行锁不是“查完就放”，而是遵循两阶段锁协议：锁在需要时加，但直到 COMMIT 或 ROLLBACK 才统一释放。这意味着锁持有时间 ≈ 整个事务执行时间，而非单条 SQL 时间。
- 常见陷阱：在事务里先做耗时操作（如调用外部 API、复杂计算），再执行
UPDATE …… FOR UPDATE→ 锁被长时间占用，拖垮并发 - 优化建议：把加锁操作尽量往后移，且确保事务块最小化；避免在事务中混入非数据库逻辑
- 验证方法：
SHOW ENGINE INNODB STATUSG查看
TRANSACTIONS部分的锁等待与持有信息
行锁不是开关，而是一套依赖索引、隔离级别、事务边界和执行路径的联动机制。最容易被忽略的，其实是「无索引导致的锁升级」和「间隙锁在范围查询中的扩散效应」——它们往往在压测时才突然暴露，且很难从 SQL 表面看出问题。
