首批通过分布式安全可靠测评,为关键业务系统打造
batch insert 大量硬解析问题的原因和解决方法
更新时间:2026-05-14 07:41
问题现象
用户 batch insert 语句有大量硬解析,在日志中发现如下日志,怀疑是 plan_cache 内存不足,租户规格 64C/256G 将 plan_cache 内存比例从 5% 提升到 15% 没有解除问题。



关键信息
发现 batch insert 语句有大量硬解析。
大量 batch insert 没有命中 plan cache 共享计划走硬解析,找到具体 SQL 执行第二次能命中计划,并不是单个 SQL 的计划到达 200 个计划的限制导致无法命中 PlanCache.
经过排查分析发现具体是表中的 binary 字段位置变化影响的,当批插的方式是拼接 SQL 语句批插时,建议业务拼 insert 语句时候控制字段和 value 固定下顺序,测试是否能共享计划 RT 降下来。
问题原因
用户的 SQL 是 insert 语句其中 有 500 values 拼成的长 SQL,并且 values 值的顺序与字段的位置不是固定的,PlanCache 有硬编码的限制 PCV Set 下可以存放的计划个数上限 200,这里并不是单个 SQL 的计划到达限制导致无法命中 PlanCache 这里看着是 insert 语句和 plan cache 使用参数化之后的 SQL 作为 plan cache key,不稳定的原因就是 sql txt 和上次 insert 语句参数化之后不一样导致 entry does not exist, 然后重新走了下 plan 新计划加入的流程 inited pcv set 加入 plan cache 经过排查发现具体是表中的 binary 字段位置变化影响的,当批插的方式是拼接 SQL 语句批插的,建议业务拼 insert 语句时候控制字段和 value 固定下顺序,测试下是否能共享计划 RT 降下来,示例如下。


问题的风险及影响
batch insert 语句有大量硬解析平均耗时增加。
影响租户
影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户,对于 SYS 租户无影响。
适用版本
OceanBase 数据库所有版本。
解决方法及规避方式
业务拼 insert 语句时候控制字段和 value 固定下顺序,SQL ID 能命令下来也能命中计划 SQL RT 降下来符合预期。