咨询：Hibernate中首次SQL插入耗时为何远超后续插入？

这种第一条Hibernate插入耗时远超后续的情况，我做项目时也碰到过，大概率是以下几个原因导致的：

1. Hibernate的首次SQL语句编译与缓存 #

Hibernate第一次执行针对某个实体的插入操作时，得完成一系列额外工作：把实体映射规则转换成原生SQL、编译成JDBC的PreparedStatement、处理参数绑定规则、校验映射元数据等等。这些编译和准备工作都会产生额外耗时，而后续执行同类型插入时，Hibernate会直接复用已经缓存好的编译结果，速度自然大幅提升。

你用Oracle SQL Developer直接执行原生SQL时，跳过了Hibernate的这些编译步骤，第一次执行当然快。你可以观察Hibernate的DEBUG日志，第一次执行时会有类似Preparing SQL statement的编译相关日志，后续执行就不会再出现了。

2. 数据库端的硬解析开销 #

Hibernate默认使用预编译语句（PreparedStatement），第一次执行这条插入SQL时，数据库需要做硬解析——也就是生成执行计划并缓存。后续执行时，数据库会复用缓存的执行计划（软解析），耗时就会显著降低。

而SQL Developer执行静态SQL时，可能数据库已经有过相同语句的执行计划缓存，或者静态SQL的解析开销本身就比预编译语句的首次硬解析小，这也会放大两者的耗时差异。

3. Hibernate Session的首次关联关系预处理 #

你的父实体存在一对一和一对多映射，第一次执行save时，Hibernate需要遍历并校验这些关联映射的元数据，准备关联实体的插入逻辑（比如确认关联实体的状态、生成关联SQL的序列）。这些预处理工作的耗时会被算在第一条插入SQL的执行时间里，而后续执行时，元数据已经加载完成，关联关系的处理逻辑也已经准备好，耗时自然就降下来了。

4. JDBC驱动的首次初始化开销 #

虽然你排除了Session初始化和JDBC连接获取的耗时，但JDBC驱动在第一次执行SQL时，可能会加载数据库特定的类型转换类、初始化内部缓存结构，这些额外开销也会被计入第一条SQL的执行时间中，后续执行就可以直接复用这些初始化后的资源。

验证方法 #

• 连续执行多次save操作，观察后续插入的耗时是否稳定在20ms左右，如果是，基本可以确认是首次初始化/编译的冷启动开销；
• 开启Hibernate的org.hibernate.type日志，查看第一次执行时是否有额外的类型处理或元数据加载日志；
• 用Oracle的性能工具（比如AWR报告、SQL Trace）查看第一条插入SQL的等待事件，确认是否存在硬解析相关的等待。

总的来说，这种差异属于正常的冷启动现象，不是Hibernate的性能问题，而是首次执行时的必要准备工作导致的。

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