金宇澄先从一个真实的问题说起。前阵子有个朋友问我，他们系统里有一张订单扩展表，字段有三十多个，其中一半是业务方临时加的冗余标记，今天加一列明天改一列，每次都要改Hibernate实体类、改映射关系、重新打包上线。他问我：这张表能不能不交给Hibernate，直接用SQL读写？我说当然可以，但你需要想清楚的不只是这张表怎么写，而是整个项目从那一刻起就进入了"混合持久化环境"。Hibernate继续管它擅长的领域模型和关联关系，JDBC Template乃至MyBatis去接那些字段不稳定的宽表、报表统计和批量任务，两边共存于同一个数据库、同一个事务边界内。
这不是"偷懒"，也不是技术洁癖的妥协。实际上，绝大多数跑了三五年以上的业务系统，早就处于某种混合状态，只是没人给这种状态起名字。很多人焦虑的是：Hibernate和原生SQL混用会不会冲突？事务会不会乱？缓存会不会失效？本文就围绕这一主题展开，把我在实际项目中踩过的坑、验证过可行的策略、以及最终沉淀下来的一套"混合持久化环境使用Hibernate"的实践方案拆开讲清楚。内容适合那些正在用Hibernate/JPA，又不得不面对SQL、多ORM、NoSQL共存的开发者，也适合准备接手老项目的同学。
1. 为什么好好的项目会走到"混合持久化"这一步
1.1 从一次"能不能别全用Hibernate"的争论说起
朋友问的那张订单扩展表，本质上暴露了Hibernate的一个特性：它让"数据模型"和"Java对象模型"强绑定。实体类的字段、类型、关联关系一旦确定，改起来就要经历"数据库DDL变更—实体类变更—映射关系核对—重新编译部署"这条完整链路。对稳定业务来说这是优势，因为类型安全、IDE支持好、无痕的延迟加载让开发效率很高；但对那种字段像流沙一样的表，优势就会反过来变成负担。
于是团队里很容易出现一种声音：这张表直接用JdbcTemplate写两个方法，插入和查询都走SQL，不香吗？确实香。但问题也随之而来：如果一条业务逻辑里既要用Hibernate更新订单主表，又要用JdbcTemplate更新扩展表，事务怎么保证？如果一个查询返回的DTO里既有Hibernate加载的实体属性，又有JdbcTemplate查出来的统计字段，会话和连接管理怎么做？这些问题不解决，混用就是埋雷，稍微一碰就炸。
1.2 生产环境里最常见的四类混合场景
- 第一类是历史系统接管，老库里有一堆设计得比较随意的表，主外键都没几个，强行用Hibernate映射成实体反而别扭，不如SQL直读。
- 第二类是复杂报表统计，多表JOIN、多层子查询、动态条件拼装，Hibernate的Criteria和HQL在这类场景下可读性差、优化空间小，SQL的可控性优势就体现出来了。
- 第三类是边缘写入场景，比如批量导入、定时跑批、一次性数据订正，这些操作关心吞吐量而不是领域模型，用JDBC Batch或者StatelessSession更舒服。
- 第四类是多技术栈团队协作，部分服务用MyBatis，部分服务用JPA，两边共享同一套数据库Schema，在代码层面不得不交叉调用。
1.3 混合持久化不是偷懒，是架构对现实的妥协
很多架构师一听到混用就皱眉，觉得这是技术栈不统一、规范混乱的表现。但我观察到的真实情况是：一个运行了多年的系统，如果说"我们只用一种持久化方式"，那多半是嘴上的说法，而不是代码里的事实。Hibernate处理领域模型很强势，但在复杂查询、动态列、大规模批量更新上，它需要SQL来兜底。反过来，纯JDBC/MyBatis的团队在维护一对多、多对多的对象嵌套关系时，又需要Hibernate这样的ORM来节省重复劳动。
所以混合持久化不是要不要的问题，而是怎么面对的问题。用得好，它是一套"各取所长"的组合拳；用不好，才是事务错乱、会话泄漏的灾难现场。关键就在于边界、基础设施和事务纪律。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 边界怎么画：哪些实体该进Hibernate，哪些该走原生访问
2.1 一个最实用的切割维度：按数据域划分
网络上关于"什么时候用ORM、什么时候用SQL"的讨论很多，有的按操作类型分，有的按性能要求分。我在实践后觉得最可执行的规则是：按数据域划分，而不是按操作划分。
什么意思呢？同一张表，要么完全交给Hibernate管理，要么完全交给SQL访问层管理，不要两边同时操作。比如订单主表、订单明细表、客户表、商品表这些承载核心业务关系的数据，归Hibernate管，因为对象之间的导航很频繁；而订单扩展属性表、操作日志表、报表聚合表、临时中间表，归SQL访问层管，因为它们的形态不稳定、访问模式简单、几乎没有对象导航需求。
如果按操作类型分，比如"写走Hibernate、读走SQL"，很容易出现一个问题：Hibernate的一级缓存和二级缓存里存着旧状态的实体，而SQL读出来的是最新数据，两条路径对同一份数据出现不同的"视图"，排查起来非常痛苦。
2.2 一张表只允许一个所有者
我给自己定过一条纪律：任何一张业务表，在应用代码里必须只有一个持久化所有者。 要么你是Hibernate实体，要么你是JdbcTemplate/MyBatis的查询对象，不能两边都建一套映射。这条规则看起来简单，执行起来却经常被打破。常见的情况是：某团队把Customer表配成了Hibernate实体，后来另一个同事图省事，直接写了一条JdbcTemplate的update语句去改Customer表某几个字段。结果就是Hibernate的二级缓存里还是旧值，界面上看到的却是新值，数据明明已经改成功，但查询结果就是不对。
为什么强调"所有者"？因为持久化不只是增删改查，它还包括状态管理、缓存管理、并发控制。Hibernate拥有这张表时，它帮你管缓存、管脏检查、管乐观锁；你绕过它直接改库，它对你的越权行为毫无感知。反过来，如果表的所有者是SQL访问层，那Hibernate也不要去碰它，更不要试图把它Load成实体再save，因为中间隔着一层不同的状态管理语义。
2.3 那些"看起来能映射、其实不该映射"的伪实体
我见过不少团队把报表宽表做成Hibernate实体，理由是"既然有主键，映射起来也不难"。但从实践看，有几类表非常不适合纳入Hibernate实体管理：
- 字段经常动态增减的业务扩展表，每次加列都要改实体的滋