表新增字段后查询性能下降的原因和解决方法

问题现象

表新增字段后，查询语句的投影列（SELECT LIST）包含新增字段时的性能比不包含新增字段的性能大幅下降，执行时间从 0.7s 增高到 8-9s，执行合并、刷新 KVCACHE 也无法提升查询性能。

不带新增字段的查询（0.7s）：

select old_col from table_t1 where col1 = '01661560012000126' AND col2 between '2024-05-08' AND '2024-05-08';

带一个新增字段查询（9s）：

select old_col,new_col_1 from table_t1 where col1 = '01661560012000126' AND col2 between '2024-05-08' AND '2024-05-08';

两个查询均使用全表扫描。根据 SQL_AUDIT 的信息，不带新增列的查询执行全表扫描仅扫描了 27 条记录，而带新增列的查询执行全表扫描扫描了全表所有的记录（> 1000万）。

问题原因

查询不带新增字段时，OceanBase 可以执行查询下压（Filter Push Down），即存储层直接根据微块的 Meta 信息来过滤 WHERE 子句中的 Filter 条件，无需解码、扫描不满足条件的微块，全表扫描的效率比较好。当查询带新增字段时，因为 Major SSTable 中的数据并没有按照新增字段后的 DDL 重写，OceanBase 无法执行查询下压，全表扫描时需要对每一个微块进行解码然后再对记录进行匹配，因此是真正的全表扫描，性能较差。

手动执行合并后带新增字段的查询性能没有得到提升，是因为渐进合并机制下 DDL 变更导致的数据重写会分散到多个合并中渐进完成，只有当所有的数据均按照新的 DDL 重写一遍后，查询下压才能执行，查询性能才会提升。

关于查询下压的更多信息，详情可参见：查询处理章节中 查询下压 内容。

适用版本

OceanBase 数据库 V3.x、V4.x 版本。

解决方法

方法一： 添加索引，使用索引扫描而非全表扫描。

方法二： 修改表的属性 progressive_merge_num=1，禁止渐进合并，然后手动发起一次合并。