SELECT ... FOR UPDATE 默认加行级排他锁，但必须WHERE条件命中索引（如主键），否则退化为全表锁；需显式开启事务才能持久生效，并在RR隔离级别下自动加间隙锁防幻读。
for update 加的是行锁，但前提是 WHERE 条件命中索引
结论很直接：SELECT ... FOR UPDATE 默认加的是**行级排他锁（X锁）**，不是表锁——但这个“默认”有个硬性前提：查询必须走索引（最好是主键或唯一索引）。否则 MySQL 会退化为**整张表锁**，并发能力瞬间归零。
为什么？因为 InnoDB 的行锁是建立在索引记录上的。没索引 → 找不到精确的索引项 → 只能扫描全表 → 为避免幻读和保证一致性，InnoDB 会升级为表级意向排他锁（IX）+ 每行都加 X 锁，效果等同于锁表。
- ✅ 正确姿势：
SELECT * FROM user WHERE id = 123 FOR UPDATE;
（id是主键 → 锁单行） - ❌ 危险姿势：
SELECT * FROM user WHERE name = 'Alice' FOR UPDATE;
（name无索引 → 全表扫描 → 实质锁表） - ⚠️ 边界情况：
SELECT * FROM user WHERE status = 'active' FOR UPDATE;
（status有索引但区分度极低，如只有 'active'/'inactive' 两值 → 可能锁大量行，甚至被优化器判定为全表扫描）
锁什么时候生效？事务不显式开启就白加
FOR UPDATE 不是“一写就锁”，它依赖事务生命周期。MySQL 默认 autocommit = 1，意味着每条语句都是独立事务——SELECT ... FOR UPDATE 执行完立刻提交，锁也立刻释放，根本起不到保护作用。
真正有效的加锁，必须手动开启事务，并在锁住数据后、业务逻辑处理完再提交：
- 必须先执行：
SET autocommit = 0;
或START TRANSACTION;
- 再执行加锁查询：
SELECT * FROM account WHERE id = 1001 FOR UPDATE;
- 然后做业务判断/计算/更新：
UPDATE account SET balance = balance - 50 WHERE id = 1001;
- 最后才
COMMIT;
（或ROLLBACK;
）释放锁
漏掉 START TRANSACTION 或提前 COMMIT，等于没锁。
锁的范围不止“查到的行”：间隙锁（Gap Lock）会悄悄参与
在 REPEATABLE-READ 隔离级别下（MySQL 8.0 默认），FOR UPDATE 不仅锁住 WHERE 匹配到的**现有记录**，还会锁住这些记录之间的**间隙（Gap）**，防止其他事务插入新行造成幻读。
例如：
SELECT * FROM order WHERE amount > 100 FOR UPDATE;若当前表中存在
amount 值为 150、200 的两行，则不仅这两行被锁，连 (100, 150)、(150, 200)、(200, +∞) 这些区间也会被加间隙锁——别人插不了 amount=120 或 amount=250 的新订单。
- 这是保障可重复读的关键机制，但也是死锁高发区：两个事务分别锁了不同间隙又反向请求对方间隙，就卡住了
- 如果确定不需要防幻读（比如纯更新已知主键），可用
SELECT ... FOR UPDATE NOWAIT（MySQL 8.0.1+）或降低隔离级别，但需权衡一致性
常见踩坑：锁表、死锁、锁失效，90% 出在这里
真实线上问题往往不是“会不会加锁”，而是“为什么加了却没用”或“为什么整个库慢了”。几个高频雷区：
-
没索引还敢用 FOR UPDATE：看执行计划
EXPLAIN，发现type = ALL或key = NULL，马上加索引，别硬扛 -
WHERE 条件含函数或隐式转换：如
SELECT * FROM user WHERE DATE(create_time) = '2025-12-29' FOR UPDATE;
→ 索引失效 → 锁表 -
锁粒度失控：用
LIKE '%abc'、OR多条件、IN大列表，都可能导致扫描行数暴增，锁住成百上千行 - 事务时间过长：锁住一行后去调外部 HTTP 接口、做复杂计算，其他事务干等 → 超时或堆积 → 整体吞吐暴跌
最隐蔽的一点：锁是“事务级”的，不是“语句级”的。哪怕你只查一行，只要事务没结束，这行就一直被占着——所以业务逻辑里“一锁二判三更新”要快，别拖。
