SpringBoot执行SELECT时触发CannotAcquireLockException问题排查求助

核心问题梳理 #

• 普通单表单行SELECT抛出CannotAcquireLockException，但确认未使用UPDATE或SELECT FOR UPDATE语句
• 疑问CrudRepository是否会自动将查询标记为写操作并加锁
• 需要确认查询是否被设置为只读

1. CrudRepository的默认行为 #

CrudRepository提供的基础查询方法（如findById、findByXXX等）默认是只读查询，不会自动加锁或标记为写操作。但以下几种场景可能导致锁冲突：

• 事务传播配置问题：如果SELECT方法被嵌套在一个写事务中（比如外层方法带有@Transactional且未指定readOnly=true），整个事务会被数据库视为读写事务，此时若与晨间合并流程的写事务产生锁竞争，就可能触发异常。
• 实体类的乐观锁配置：如果目标表实体加了@Version注解，查询时会附带版本校验，但一般不会引发锁等待，除非合并流程正在更新对应行的版本号。
• 自定义查询的锁注解：如果是自定义的查询方法，若添加了@Lock注解（如@Lock(LockModeType.PESSIMISTIC_WRITE)），会强制给查询加锁，导致普通SELECT变成锁查询。

2. 如何确认查询是否为只读事务 #

可以通过以下几种方式快速验证：

• 检查事务注解：查看SELECT方法或其调用者的方法上是否有@Transactional注解，若未设置readOnly = true，则事务默认是读写模式。
• 开启SQL与事务日志：在SpringBoot配置文件中添加以下配置，打印执行的SQL和事务属性：

  logging.level.org.hibernate.SQL=DEBUG
  logging.level.org.springframework.transaction=DEBUG
  

  日志中会显示事务是否标记为只读，以及实际执行的SQL是否包含锁相关语句。
• 查看CrudRepository方法定义：如果是自定义查询方法，检查是否带有@Lock或其他会修改查询行为的注解。

3. 锁冲突的解决建议 #

• 给SELECT方法显式添加只读事务：在查询方法上标注@Transactional(readOnly = true)，这会告知Spring和持久化框架（如Hibernate）以只读事务处理该查询，优化执行计划并避免不必要的锁竞争。
• 优化晨间合并流程：将批量合并操作拆分为更小的批次，缩短事务持有锁的时间，减少与查询的冲突概率。
• 确认数据库隔离级别：若数据库使用SERIALIZABLE隔离级别，普通SELECT会加锁，建议调整为InnoDB默认的REPEATABLE READ级别，此时普通查询采用快照读，不会与写事务产生锁冲突。

内容的提问来源于stack exchange，提问作者Nick.Mc