SELECT FOR UPDATE必须在显式事务中才生效；autocommit=1时锁立即释放，等同于未加锁；需走索引才能行锁，否则升表锁；RR级别下还加间隙锁，RC级别可避免。
SELECT FOR UPDATE不加事务等于没锁
MySQL 8.0 中 SELECT ... FOR UPDATE 必须在显式事务内才真正生效。默认 autocommit=1，单条语句执行完立刻提交，锁秒放——你看到“没锁住”，其实是锁根本没来得及起作用。
实操建议：
- 先确认状态：
SELECT @@autocommit;，返回0才安全；若为1，必须执行START TRANSACTION;（比SET autocommit = 0更清晰、不易遗漏） - 所有依赖锁的操作（包括后续
UPDATE）必须在同一事务中完成 - 务必显式
COMMIT;或ROLLBACK;；漏掉会导致长事务、锁堆积、阻塞其他更新
WHERE条件必须走索引，否则锁全表
SELECT ... FOR UPDATE 的行锁能力完全依赖索引。InnoDB 锁的是索引项，不是数据行本身。没索引 → 全表扫描 → 每行都加 X 锁 + 间隙锁 → 效果等同于表锁。
常见错误现象：明明只查 id = 123，却导致整张 orders 表写入卡死。
检查方法：EXPLAIN SELECT * FROM orders WHERE id = 123 FOR UPDATE;
-
type字段必须是const、ref或range；若为ALL或index，说明没走有效索引 -
key字段必须显示具体索引名（如PRIMARY或idx_order_no），不能是NULL - 避免隐式转换：字段是
BIGINT，却传字符串'123'，索引会失效 - 联合索引要满足最左前缀，
WHERE status = ?对(user_id, status)无效
RR隔离级别下默认带间隙锁，INSERT也可能被阻塞
MySQL 8.0 默认隔离级别是 REPEATABLE READ，此时 SELECT ... FOR UPDATE 不仅锁匹配行，还锁住索引间隙（Gap Lock），防止幻读。但业务上常不需要这个语义，反而导致无关 INSERT 被卡住。
典型表现：
- 表中有
id = 1, 5, 10，执行SELECT * FROM t WHERE id BETWEEN 3 AND 7 FOR UPDATE - 会锁住间隙
(1,5)和(5,10)，INSERT INTO t (id) VALUES (4)就会被阻塞
如果业务只需锁“已存在”的行（比如纯扣库存、改状态），可临时切到 READ COMMITTED：
SET TRANSACTION ISOLATION LEVEL READ COMMITTED; —— 此后该事务内只锁行，不锁间隙。
不是所有UPDATE都需要前置SELECT FOR UPDATE
InnoDB 在执行 UPDATE 时，只要 WHERE 条件命中索引，就会自动加行锁。多一次 SELECT ... FOR UPDATE 只是白耗一次查询和锁开销。
真正需要先查后锁的场景只有两个：
- 业务逻辑依赖旧值做判断，比如：先查
stock是否 ≥ 1，再决定是否扣减；这个“查”和“判断”必须与锁绑定在同一事务中 - 需读取多个字段参与计算（如
balance和version），且后续UPDATE要基于这些值做原子更新
简单覆盖更新（如 UPDATE t SET status = 'done' WHERE id = 123）直接上 UPDATE 即可，无需前置 SELECT FOR UPDATE。
最容易被忽略的点是锁的“范围”和“持续时间”：你以为只锁了一行，其实可能锁了整个间隙；你以为只锁几毫秒，结果因调第三方接口或日志打印拖成秒级持有。锁不是加了就万事大吉，而是从加锁那一刻起，每一步操作都在放大阻塞风险。
