SELECT FOR UPDATE只在事务中生效，因为MySQL默认autocommit=1，语句执行完立即提交导致锁瞬时释放；必须显式BEGIN/START TRANSACTION开启事务，锁才持续到COMMIT或ROLLBACK。
SELECT FOR UPDATE 为什么只在事务里生效
MySQL 的 SELECT FOR UPDATE 不是独立语句，它本质是给后续 UPDATE 或 DELETE 铺路的“加锁读”——只有在显式开启的事务中（BEGIN 或 START TRANSACTION），它才会真正持有行锁；否则自动提交模式下，语句一执行完锁就释放，根本起不到保护作用。
常见错误现象：SELECT FOR UPDATE 执行后立刻 UPDATE，但并发请求仍出现脏写或覆盖，往往就是忘了包在事务里。
- 必须用
BEGIN显式开启事务，不能依赖隐式自动提交 - 事务结束前（
COMMIT或ROLLBACK）锁一直持有，其他事务对同一行执行SELECT FOR UPDATE或UPDATE会阻塞等待 - InnoDB 行锁生效前提是查询条件命中索引；全表扫描会升级为表锁，极大降低并发能力
WHERE 条件没走索引会导致锁表
SELECT FOR UPDATE 的锁粒度完全取决于执行计划是否使用索引。如果 WHERE 中的字段没有索引，或者用了函数、隐式类型转换导致索引失效，InnoDB 就不得不扫描全表——此时不是逐行加锁，而是对所有扫描过的记录加锁，甚至可能锁住间隙（Next-Key Lock），实际效果接近表级互斥。
验证方式：执行 EXPLAIN SELECT ... FOR UPDATE，看 type 是否为 range/ref 等高效类型，且 key 列显示实际使用的索引名。
- 主键、唯一索引字段最安全；普通二级索引也行，但要注意
SELECT FOR UPDATE会同时锁住索引记录和对应的聚簇索引记录 - 避免
WHERE status = 'pending' AND created_at > NOW() - INTERVAL 1 DAY这类范围查询没索引的情况 - 字符串比较注意字符集和排序规则一致，否则
WHERE user_id = 123（user_id是字符串类型）会因隐式转换跳过索引
UPDATE 之前不加 SELECT FOR UPDATE 的典型竞态场景
比如扣减库存：SELECT stock FROM products WHERE id = 123 得到当前值 5，然后 UPDATE products SET stock = 4 WHERE id = 123。两个并发请求都读到 5，都写入 4，最终库存变成 4 而不是预期的 3——这就是典型的“读-改-写”竞态。
用 SELECT FOR UPDATE 可破局，但要注意它只锁住查到的行，不锁住“不存在”的逻辑状态。例如“余额不足时拒绝下单”，仅靠 SELECT FOR UPDATE 无法阻止两个事务都读到足够余额后继续执行。
- 正确姿势：在事务内先
SELECT stock FROM products WHERE id = 123 FOR UPDATE，再判断是否 >= 扣减量，最后UPDATE - 如果业务需要检查多个行（如订单含多个商品），务必一次性查全并加锁，避免分多次
SELECT FOR UPDATE引发死锁 - 不要在
SELECT FOR UPDATE后做耗时操作（如调外部 API、复杂计算），否则锁持有时间过长，拖慢整体吞吐
死锁检测与超时设置很关键
MySQL 默认开启死锁检测（innodb_deadlock_detect = ON），一旦发现循环等待会主动回滚其中一个事务并报错 Deadlock found when trying to get lock。但这不是万能的——高并发下频繁死锁会显著增加失败重试成本。
更可控的做法是设短超时：SET innodb_lock_wait_timeout = 5（单位秒），让等待锁的事务在 5 秒后自动失败，避免无限阻塞。注意这个变量是 session 级的，需在事务开始前设置。
- 应用层必须捕获
Deadlock found和锁等待超时错误（Lock wait timeout exceeded），并实现幂等重试逻辑 - 避免跨多张表按不同顺序加锁（如事务 A 先锁表 X 再锁表 Y，事务 B 反过来），这是死锁高频来源
- 尽量缩短事务生命周期：加锁 → 判断 → 更新 → 提交，中间别掺杂非数据库操作
锁本身不难写，难的是确认它真锁住了想锁的那几行，且没把别的路一起堵死。每次加 SELECT FOR UPDATE，都得反问一句：这行是不是真被索引定位到了？这个事务里还有没有其他锁？超时够不够短？
