复制表场景无法命中 Plan Cache 问题分析与解决

问题现象

在涉及分区表与复制表关联的 SQL 查询场景中，SQL 生成执行计划的时间从通常的毫秒级上升到了秒级，具体表现为 get_plan_time 显著增加至 8.1 秒以上。此问题在业务平稳运行一段时间后突然出现，且在高并发场景下尤为明显。

从问题 SQL 的 GV$OB_PLAN_CACHE_PLAN_STAT 视图查询结果中可以看到，is_hit_plan 字段为 0，表示未命中 Plan Cache，get_plan_time 为 8184399 微秒（约 8.18 秒），elapsed_time 为 8605859 微秒（约 8.6 秒）。

同时，在 Observer 日志中观察到大量 database not exist 的 INFO 级别日志，以及 failed to inner add cache obj 和 fail to add plan 的 WDIAG 日志，错误码为 -4016。日志中还出现了 The Latch wait too much time 的告警，表明存在锁等待。

问题原因

该问题出现在分区表与复制表关联的查询场景中。由于计划生成约束存在缺陷，导致硬解析无法命中 Plan Cache。在高并发场景下，大量的硬解析会引发 Plan Cache 锁等待时间过长，进而导致 get_plan_time 显著增加。

经过验证，4.2.5.5 版本已修复此问题。

关键信息

1. 在复制表场景叠加高并发场景下，SQL 生成执行计划时间显著增加，get_plan_time 达到 8.1 秒以上。
2. 涉及复制表的 SQL 大量查询计划无法命中 Plan Cache，导致硬解析并引发 Plan Cache 锁等待。
3. 问题租户的 PRIMARY_ZONE 设置为 RANDOM，业务 SQL 涉及分区表与复制表的关联查询。
4. 使用 FLUSH PLAN CACHE 和绑定 Outline 可以暂时缓解问题。

问题的风险及影响

• 大量 SQL 查询计划无法命中 Plan Cache，导致频繁硬解析。
• 在高并发场景下，硬解析可能导致严重的性能下降，影响业务系统的响应速度和用户体验。

适用版本

• 影响版本： 4.2.1.x
• 修复版本： 4.2.5 BP4 及之后的版本

解决方法

• 升级到修复版本： 建议将 OceanBase 数据库升级到 4.2.5 BP4 或之后的版本，该版本中对复制表进行了重构并修复了相关问题。
• 绑定执行计划： 对于受影响的 SQL 查询，可以通过绑定特定的执行计划来避免硬解析，从而减少执行计划生成的时间。

规避方式

• 避免在高并发场景下频繁执行涉及分区表与复制表关联的复杂 SQL 查询。
• 对于已知受影响的 SQL 查询，可以提前绑定有效的执行计划。
• 计划升级到 4.2.5 BP4 或之后的版本，从根本上解决问题。