如何禁用Hibernate变更检查 优化大数据量查询性能

你当前手动切换FlushMode的临时方案存在明显隐患：如果方法执行中途抛出异常，重置为AUTO模式的逻辑不会执行，会导致当前事务上下文的FlushMode状态泄漏，后续写操作可能出现不提交、脏数据不刷库的问题。

以下是生产环境通用的落地方案，按推荐优先级排序：

• 首选方案：使用只读事务注解，无侵入实现自动优化
  你之前注释中提到的@Transactional(readOnly = true)是行业通用的标准解法，不存在顶层事务难管控的问题：Spring等主流框架的事务传播机制默认会加入外层已存在的事务，在Repository层或查询类Service方法上加该注解时，如果外层是写事务，只读标识不会强制覆盖外层事务配置；如果当前方法是事务入口，框架会自动通知Hibernate做三层优化：
  1. 自动将FlushMode切换为MANUAL，完全关闭查询触发的autoFlush脏检查
  2. 跳过一级缓存的脏对象状态比对，因为只读事务不会提交实体修改
  3. 自动给JDBC连接设置只读标识，进一步降低数据库交互开销
     整个过程完全不需要手动修改FlushMode，没有任何业务代码侵入。
• 过渡方案：自定义AOP注解统一管控FlushMode，你提到的AspectJ思路完全可行
  如果因为历史项目事务配置混乱，暂时没法全量推广只读事务，可以用你考虑的自定义注解方案，核心是要做异常安全的状态兜底：
  1. 定义方法级注解比如@DisableAutoFlush，标记所有不需要触发autoFlush的纯查询方法
  2. 写切面拦截标记了该注解的方法：执行前获取当前上下文的EntityManager，记录原有FlushMode后设置为COMMIT；用try/finally块包裹业务逻辑，无论方法正常返回还是抛出异常，都在finally块中还原原始FlushMode，彻底避免状态泄漏
  3. 直接给对应查询方法加注解即可，不需要在业务代码里写任何FlushMode切换逻辑，比硬编码可靠且无冗余。
• 长期根治方案：从根源减少一级缓存托管的实体数量
  性能问题的本质是一级缓存中堆积的托管实体过多，每次autoFlush触发脏检查时需要全量遍历所有托管实体做状态比对，查询次数越多累积开销越大，长期优化必须做两点改造：
  1. 大列表查询场景避免直接加载全量实体，用DTO投影查询直接返回需要的字段，不要把无关字段、关联实体全部加载到一级缓存
  2. 重构当前全量加载后在内存做时间范围过滤、分页的逻辑，把筛选、分页条件全部下推到SQL层执行，避免把全表数据加载到应用内存；如果确实需要批量处理大量数据，定期调用entityManager.clear()清空一级缓存，避免托管实体持续堆积。

注意：就算暂时保留手动切换FlushMode的逻辑，也必须把重置AUTO模式的代码放到finally块中，避免异常场景下的状态泄漏。

内容的提问来源于stack exchange，提问作者WBLord