SELECT FOR UPDATE 未锁住行的根本原因是WHERE条件未命中索引，导致无法加Record Lock；若全表扫描则可能锁全表或加间隙锁，务必确保查询字段已建索引并用EXPLAIN验证。
SELECT FOR UPDATE 为什么没锁住行？
常见错误现象是：执行了 SELECT ... FOR UPDATE，但并发更新仍出现超卖或重复写入。根本原因不是语句写错了，而是它锁的对象取决于查询条件是否命中索引。
如果 WHERE 条件用的是主键或唯一索引字段（如 id = 123），InnoDB 加的是 Record Lock，只锁那一条记录；但如果条件走全表扫描（比如 status = 'pending' 且该字段无索引），InnoDB 会把扫描到的所有行都加锁，极端时甚至升级为表锁——这既拖慢性能，又容易引发死锁。
实操建议：
- 务必在
FOR UPDATE的WHERE字段上建立索引，否则锁行为不可控 - 用
EXPLAIN检查执行计划，确认是否走了索引扫描（type字段为const、ref或range） - 避免在事务中做耗时业务逻辑，锁持有时间越长，阻塞越严重
- 若查询结果为空，InnoDB 仍可能加 Gap Lock（间隙锁），导致后续插入被阻塞——这不是 bug，是可重复读隔离级别的正常行为
UPDATE 带 version 条件为什么影响行为为 0？
这是乐观锁最典型的失败信号：UPDATE ... WHERE id = ? AND version = ? 返回影响行数为 0，说明数据已被其他事务修改过，当前版本已失效。
关键点在于：这个判断必须由应用层主动检查，MySQL 不会抛异常，也不会自动重试。很多开发者只写了 SQL，却忘了在代码里判断 ROW_COUNT() 或 MyBatis 的 update 返回值。
实操建议：
- 每次执行乐观锁
UPDATE后，必须检查返回的受影响行数，为 0 就意味着冲突 - 重试逻辑不能无限循环，应设最大重试次数（如 3 次），避免雪崩
- version 字段必须是
INT类型且默认非空（如DEFAULT 0），不能用TIMESTAMP——因为毫秒级精度在高并发下仍可能碰撞 - 不要在同个事务里先
SELECT再UPDATE，否则失去乐观锁“无锁读”的意义；应确保读取和更新之间无其他写操作干扰
悲观锁和乐观锁能混用吗？
可以，但必须分清边界：悲观锁管“临界资源抢占”，乐观锁管“状态最终一致性”。比如订单支付场景中，用 SELECT ... FOR UPDATE 锁住账户余额防止透支，同时用 version 字段控制订单状态从 “待支付” → “已支付”，两者职责不重叠。
混用的风险在于：如果在同一个事务里对同一行既加了 FOR UPDATE，又做了带 version 的 UPDATE，乐观锁校验就退化成冗余逻辑——因为悲观锁已经保证了独占性，version 校验不再必要。
实操建议：
- 优先选一种策略贯穿整个业务流程，避免人为增加复杂度
- 混合使用时，悲观锁应放在事务最开始，且只用于真正需要强互斥的环节（如库存扣减、资金划转）
- 乐观锁更适合异步任务、消息队列消费等无法长期持锁的场景
- 注意隔离级别：悲观锁在
READ COMMITTED下只锁命中的行；在REPEATABLE READ下还会加 Next-Key Lock，影响范围更大
为什么乐观锁重试后还是失败？
这不是锁机制的问题，而是业务设计缺陷。典型例子是秒杀场景：100 个请求同时读到 stock=1、version=5，第一个成功扣减后 stock=0、version=6；剩下 99 个请求重试时，仍用旧的 stock=1 做计算，再执行 UPDATE ... SET stock = 0, version = 6 WHERE version = 5，结果全失败。
问题出在“读取-计算-更新”链条中，计算环节没有基于最新值重算。真正的重试逻辑应该是：每次失败后重新 SELECT 当前库存和 version，再决定是否还能扣减。
实操建议：
- 重试时必须重新查询最新数据，不能复用第一次读到的 stock 或 version
- 对库存类场景，建议在 SQL 层直接用原子操作：
UPDATE product SET stock = stock - 1, version = version + 1 WHERE id = ? AND stock >= 1 AND version = ? - version 字段要配合
UNIQUE约束或应用层幂等控制，否则 ABA 问题（比如 version 从 1→2→1）会导致漏检 - 高并发下，单靠重试不够，需前置限流（如 Redis 计数器）或降级（如排队提示）
实际落地中最容易被忽略的，是乐观锁的“重试必须重读”和悲观锁的“锁必须落在索引上”这两条铁律。违反任意一条，都会让锁机制形同虚设。
