SELECT FOR UPDATE必须在显式事务中执行，否则autocommit=1导致锁瞬时释放；需确保WHERE条件命中索引，否则升级为表锁；锁类型取决于隔离级别，RR下为Next-Key Lock，RC下仅为记录锁。
SELECT FOR UPDATE 必须在事务中执行
单独执行 SELECT FOR UPDATE 不会加锁，MySQL 会自动提交当前语句并释放锁——这等于没锁。必须显式开启事务，且在事务提交或回滚前锁才持续有效。
常见错误是忘记 BEGIN 或 START TRANSACTION，或者用 ORM（如 Django 的 .select_for_update()）时没控制好事务边界，导致锁瞬间释放。
- 正确写法：
BEGIN; SELECT * FROM orders WHERE id = 123 FOR UPDATE; UPDATE orders SET status = 'paid' WHERE id = 123; COMMIT; - 若使用自动提交模式（
autocommit=1），需先执行SET autocommit = 0;，否则每条语句都是独立事务 - InnoDB 只支持行级锁，但若查询条件不走索引（如
WHERE name = 'xxx'而name无索引），会升级为表锁，极大影响并发
WHERE 条件必须命中索引，否则锁范围不可控
SELECT FOR UPDATE 加的是“当前读”下的记录锁（Record Lock）或间隙锁（Gap Lock），但前提是优化器能通过索引精确定位记录。否则会触发全表扫描+锁表，或锁住远超预期的索引区间。
比如 SELECT * FROM users WHERE email LIKE '%@gmail.com' FOR UPDATE，即使 email 有索引，也无法使用，最终可能锁住整个聚簇索引。
- 用
EXPLAIN确认type是const、ref或range，避免ALL或index - 主键或唯一索引查询最安全；普通索引需注意是否为最左前缀匹配
- 空值处理要小心：
WHERE status IS NULL若该列无索引或索引允许 NULL，也可能导致锁扩大
注意锁等待超时和死锁检测行为
MySQL 默认 innodb_lock_wait_timeout = 50 秒，被阻塞的 SELECT FOR UPDATE 会卡住直到超时并报错 ERROR 1205 (40001): Deadlock found when trying to get lock 或 ERROR 1205 (40001): Lock wait timeout exceeded。
这不是应用层能“重试就解决”的问题——死锁由 InnoDB 自动检测并回滚其中一方事务，而超时则是被动等待失败。两者都需要业务侧主动兜底。
- 在应用中捕获
Lock wait timeout exceeded和Deadlock found这两类错误码，而非泛化为数据库异常 - 避免跨多张表按不同顺序加锁（如事务 A 先锁
orders再锁inventory，事务 B 反之），这是死锁高发场景 - 尽量缩短事务生命周期：查完立刻更新，不要在事务里做 HTTP 请求、文件读写等耗时操作
READ COMMITTED 和 REPEATABLE READ 隔离级别对锁的影响差异大
在 REPEATABLE READ（MySQL 默认）下，SELECT FOR UPDATE 会加临键锁（Next-Key Lock），即记录锁 + 间隙锁，防止幻读；而在 READ COMMITTED 下只加记录锁，间隙锁被禁用，幻读可能发生，但锁粒度更小、冲突更少。
这意味着：同一句 SQL，在不同隔离级别下锁住的行数、等待概率、死锁风险都不同。别假设“只要加了 FOR UPDATE 就一定锁得准”。
- 若业务能接受幻读（例如秒杀库存扣减只关心已有记录），可考虑临时切到
READ COMMITTED降低锁竞争 - 修改隔离级别需全局评估：会影响所有事务，不只是当前这条
SELECT FOR UPDATE -
SELECT FOR UPDATE NOWAIT（MySQL 8.0.1+）可立即失败而非等待，适合对响应时间敏感的接口，但需处理ERROR 3572 (HY000)
真正难的不是写对那条 SQL，而是确认它锁住了该锁的行、只锁了该锁的行，并且上下游调用链里没人绕过事务、改了隔离级别、或悄悄删了索引。
