mybatis 中 select ... for update 未锁住行，根本原因是事务未开启或隔离级别不支持；必须配合 @transactional、innodb 引擎及合适隔离级别，并确保 sql 正确书写且条件命中索引。

MyBatis 中 SELECT ... FOR UPDATE 为什么没锁住行？

根本原因通常是事务未开启或隔离级别不支持。MyBatis 本身不控制事务边界，FOR UPDATE 只在数据库事务内生效，且依赖存储引擎（如 InnoDB）和隔离级别（推荐 REPEATABLE READ 或 READ COMMITTED）。

• Spring 项目中必须确保方法被 @Transactional 注解包裹，且传播行为不是 SUPPORTS 或 NOT_SUPPORTED
• MySQL 5.7+ 默认隔离级别是 REPEATABLE READ，但若应用显式设为 READ UNCOMMITTED，FOR UPDATE 会失效
• MyBatis 的 <select></select> 语句需明确写 SELECT * FROM user WHERE id = #{id} FOR UPDATE，不能靠拦截器或注解自动加锁
• 注意：若查询条件未命中索引（比如用了函数、模糊前缀 LIKE '%xxx'），InnoDB 可能升级为表锁，反而拖慢并发

乐观锁用 version 字段时，MyBatis 更新失败却不报错？

这是设计使然——乐观锁的本质是“检测冲突后放弃更新”，不是抛异常。MyBatis 的 update 方法返回值是 int（影响行数），必须主动判断是否为 0。

• SQL 需写成：UPDATE order SET status = #{status}, version = version + 1 WHERE id = #{id} AND version = #{version}
• Java 层必须检查返回值：if (mapper.updateOrder(order) == 0) { throw new OptimisticLockException("版本冲突"); }
• 别把 version 字段设为 NULL 默认值，否则首次更新时 WHERE version = NULL 永远不成立（要用 IS NULL，但和自增逻辑冲突）
• 如果用 MyBatis-Plus，UpdateWrapper 的 eq("version", entity.getVersion()) 是安全的，但记得调用 setEntityVersion() 或手动维护

FOR UPDATE 和 version 方案性能差异在哪？

不是“谁更快”，而是“谁更扛得住”。悲观锁靠数据库行锁阻塞并发，乐观锁靠重试应对冲突，二者适用场景完全不同。

• 高冲突低频写（如秒杀库存扣减）：FOR UPDATE 更稳，但连接池容易耗尽；需配合超时（lock_wait_timeout）和快速释放事务
• 低冲突高频写（如用户资料修改）：version 几乎无锁开销，但若真发生冲突（比如两人同时编辑），得重试或提示用户刷新
• MyBatis 中混合使用常见：查详情用 FOR UPDATE 锁住关键行，再校验业务规则；非核心字段更新走 version 避免长事务
• 注意：MySQL 的 FOR UPDATE 在 RR 级别下可能触发间隙锁，导致无关记录也被锁住，测试时务必用真实数据分布验证

MyBatis 动态 SQL 里拼 FOR UPDATE 容易出什么问题？

最典型的是语法错误或锁范围失控——因为 FOR UPDATE 必须紧贴 SELECT 末尾，不能被 <if></if> 拆开，也不能出现在子查询里。

• 错误写法：<if test="forUpdate">FOR UPDATE</if> → 生成 SELECT ... WHERE ... FOR UPDATE 是对的，但若 forUpdate=false，结尾多出空格或换行可能让 SQL 解析失败
• 正确做法：整个 SQL 语句按需生成，用 <trim suffix="FOR UPDATE"></trim> 或直接两个独立 <select></select> 标签（selectForUpdate / selectNormal）
• 切勿在 <foreach></foreach> 循环中对多 ID 加锁：SELECT ... WHERE id IN (...) FOR UPDATE 会锁住所有匹配行，但若部分 ID 不存在，InnoDB 仍可能锁住间隙，引发意外阻塞
• MyBatis 3.4+ 支持 useGeneratedKeys 和 FOR UPDATE 共存，但 Oracle 不支持，跨库时别默认套用

真正难的从来不是写对一行 FOR UPDATE 或加个 version 字段，而是想清楚这笔更新背后有没有其他服务也在改同一行、事务里混没混业务查询、下游会不会因锁等待超时而降级失败——这些没法靠框架自动兜底。