如何深入理解MySQL RecordLock记录锁以防止事务并发更新同一行？

本文共计1110个文字，预计阅读时间需要5分钟。

MySQL的`UPDATE`默认使用加锁级别为X+锁，但锁只存在于语句执行期间——它不能防止逻辑错误。

最常见的操作错误是写如下语句：

真正要防的是“业务意图被破坏”，不是“有没有锁”。所以第一步永远是：所有 UPDATE 必须带确定到单行的 WHERE 条件，优先用主键或唯一索引字段，比如 WHERE id = 123。

• 避免 WHERE status = 'pending' 这类条件——并发下可能多事务同时查到同一组记录，都去更新，变成竞态
• 若必须按状态筛选，就改成 WHERE id = ? AND status = 'pending'，再检查 ROW_COUNT() 是否为 1
• InnoDB 对无索引的 WHERE 会退化为锁表，不是锁一行，务必确认执行计划里 type 是 const 或 eq_ref

RecordLock 是怎么生效的？看锁是否真落到目标行上

RecordLock（记录锁）是 InnoDB 行锁的具体实现形式，但它只对索引有效。所谓“锁一行”，本质是锁住该行对应的**聚簇索引记录**（主键值）或**二级索引记录**（如果 WHERE 走的是二级索引）。没有索引，就没有 RecordLock，只有 TableLock 或 Next-Key Lock 范围锁。

验证方法很简单：

• 执行 SELECT * FROM user WHERE id = 123 FOR UPDATE 后，另开连接尝试 UPDATE user SET name='x' WHERE id = 123 —— 会被阻塞，说明 RecordLock 生效
• 换成 SELECT * FROM user WHERE name = 'alice' FOR UPDATE（name 无索引），再试同 ID 更新 —— 不阻塞，因为实际锁的是整张表或大范围间隙
• 查 information_schema.INNODB_TRX 和 INNODB_LOCKS（MySQL 5.7+ 已移除，改用 performance_schema.data_locks）可确认锁类型和对象

乐观锁 version 字段比 SELECT FOR UPDATE 更轻量

很多人一想到“防并发更新”就本能写 SELECT ... FOR UPDATE，但它要求事务全程持有锁，从查到更新完成之间任何延迟（比如网络 IO、远程调用、复杂计算）都会延长锁时间，极易引发锁等待甚至死锁。

更推荐用乐观锁，核心是一条原子 UPDATE：

UPDATE order_info SET status = 'shipped', version = version + 1 WHERE id = 1001 AND version = 5

只要 version 字段是 INT 类型、每次更新自增、且应用层校验 ROW_COUNT() == 1，就能在不加锁前提下拦截并发覆盖。注意：

• 不能用 updated_at 替代 version——毫秒级精度在高并发下大概率冲突，且时钟不同步会导致误判
• 重试逻辑必须可控，避免无限循环；建议加指数退避，最多 3 次
• 该方案在冲突率

死锁不是锁太多，而是加锁顺序不一致

两个事务分别先锁 A 行再锁 B 行，和先锁 B 再锁 A，就构成经典死锁环。InnoDB 会自动检测并回滚其中一个事务，报错 Deadlock found when trying to get lock。这不是配置问题，是代码逻辑缺陷。

解决关键在于统一加锁顺序：

• 所有涉及多行更新的业务，按主键升序排列后再批量更新，例如 UPDATE t SET x=1 WHERE id IN (100, 99, 101) 改成 WHERE id IN (99, 100, 101)
• 避免在同一个事务里混用不同索引条件查同一张表，比如先 WHERE uid=123，再 WHERE order_no='xxx'，容易因索引路径不同导致锁顺序不可控
• 监控 SHOW ENGINE INNODB STATUS 里的 LATEST DETECTED DEADLOCK 区域，看具体哪两行、哪两个事务在争抢

RecordLock 本身很可靠，但它的行为完全取决于你写的 SQL 怎么走索引、怎么组织事务边界。别指望加个锁就万事大吉，得盯着执行计划和锁等待链看。