添加列后，查询语句包含新加列时默认计划不优

摘要

当表中新增列且未完成基线数据重写时，若查询语句包含了新加列，优化器可能因无法感知存储层实际变化而错误低估全表扫描的代价，从而选择代价较低但实际执行效果不佳的计划。此时，需要对表执行全量合并以使执行计划符合预期。

问题现象

在表新增一列后，执行包含该列的查询语句时，优化器选择了全表扫描计划，但实际执行时间远高于预期。

例如，执行以下查询：

SELECT * FROM t1 WHERE workdate = '20251123';

优化器估算的全表扫描代价（est.time）低于索引扫描代价，因此默认选择了全表扫描计划。然而，实际执行该计划扫描了 639 万行数据，耗时 23.8 秒，性能远低于预期。

注意：此问题并非优化器选错了基表计划，而是其选择的计划实际执行时间过高，不符合预期。

进一步查询对应 Trace 的 SQL Audit 可以发现，大量的数据访问需要扫描磁盘，无法利用存储层的下压优化。

问题原因

在 OceanBase 数据库中，当表结构发生变化（特别是新增列）后，在完成基线数据重写之前，优化器无法感知存储层的实际变化，可能会错误地低估全表扫描的代价。

由于新列加入后，在基线数据重写完成前，优化器仍按照旧的数据分布情况来评估执行计划的成本，未能考虑到新列带来的数据访问模式变化，导致代价估算存在偏差，进而影响了执行计划的选择。

解决方案

对表执行全量合并后，优化器能够正确选择索引扫描，查询性能可恢复至预期水平。

适用版本

• 3.x
• 4.2.x
• 4.3.x

补充信息

当前 4.3.5.1 版本已修复此问题，但尚未回溯至较低版本。

对于受影响的版本，建议采取以下方式作为临时解决方案：

• 对表执行全量合并。
• 通过 SQL Plan Management（SPM）绑定索引计划。

以避免因代价估算不准导致的查询性能问题。