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 接口、做复杂计算，其他事务干等 → 超时或堆积 → 整体吞吐暴跌
最隐蔽的一点：锁是“事务级”的，不是“语句级”的。哪怕你只查一行，只要事务没结束，这行就一直被占着——所以业务逻辑里“一锁二判三更新”要快，别拖。
