首批通过分布式安全可靠测评,为关键业务系统打造
SQL 查询中使用聚合函数下压相关问题的诊断
更新时间:2026-05-15 09:06
问题现象
一个简单的 count(*) 耗时 30s 不符合预期,表的数据规模有 56717560 行。
-- 查询语句
select count(*) from xxxx_log
-- 查询语句相应的计划
===========================================================================================================================
|ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|REAL.ROWS|REAL.TIME(us)|IO TIME(us)|CPU TIME(us)|
---------------------------------------------------------------------------------------------------------------------------
|0 |SCALAR GROUP BY | |1 |2658167 |1 |30209499 |0 |2 |
|1 |└─TABLE FULL SCAN|xxxx_log(idx_ship_name)|90748096|1013446 |1 |30209499 |0 |30208207 |
===========================================================================================================================
Outputs & filters:
-------------------------------------
0 - output([T_FUN_COUNT_SUM(T_FUN_COUNT(*))]), filter(nil), rowset=256
group(nil), agg_func([T_FUN_COUNT_SUM(T_FUN_COUNT(*))])
1 - output([T_FUN_COUNT(*)]), filter(nil), rowset=256
access(nil), partitions(p0)
is_index_back=false, is_global_index=false,
range_key([xxxx_log.ship_name], [xxxx_log.id]), range(MIN,MIN ; MAX,MAX)always true
Used Hint:
-------------------------------------
/*+
*/
Qb name trace:
-------------------------------------
stmt_id:0, SEL$1
Outline Data:
-------------------------------------
/*+
BEGIN_OUTLINE_DATA
INDEX(@"SEL$1" "simba_wms_roopy_bak"."xxxx_log"@"SEL$1" "idx_ship_name")
OPTIMIZER_FEATURES_ENABLE('4.2.1.10')
END_OUTLINE_DATA
*/
Optimization Info:
-------------------------------------
xxxx_log:
table_rows:56717560
physical_range_rows:90748096
logical_range_rows:90748096
index_back_rows:0
output_rows:90748096
table_dop:1
dop_method:Table DOP
avaiable_index_name:[idx_creades, idx_ship_code, idx_ship_name, idx_scan_entrance_create_time, idx_scan_eid, idx_user_id, xxxx_log]
stats info:[version=2025-02-20 17:52:35.494088, is_locked=0, is_expired=0]
dynamic sampling level:0
estimation method:[OPTIMIZER STATISTICS, STORAGE]
Plan Type:
LOCAL
Note:
Degree of Parallelisim is 1 because of table property
关键信息
首先看计划是否有聚合函数下压。

检查参数开关。

不同参数值的含义,如下:
配置项名称:pushdown_storage_level。 模块:存储。 功能:控制存储层特性下压级别。 数据类型:int。 取值范围:[0,5]。 默认值:3(OceanBase 数据库 V3.x 版本是 2 建议修改执行查询记录下)。 使用说明:通过这个配置项可以控制多个特性的开闭,不暴露给用户。 0 -> 关闭静态数据快速扫描、filter下推、聚合下推。 1 -> 开启静态数据快速扫描。 2 -> 开启静态数据快速扫描 & filter 下推。 3 -> 开启静态数据快速扫描 & filter 下推 & 聚合下推。最近是否合并,合并后就能走下压聚合函数路径。
检查计划
explain extended搜索计划中的 Optimization Info 部分。
没有动态数据的情况下
physical_range_rows和logical_range_rows不会比 table_rows 大很多.
问题原因
执行 SQL 期间有大量的 DML 操作,导致 Major SSTable 和增量数据是有交集的,无法快速区分数据,需要查询的数据多所以执行慢,如果合并就能满足,没有动态数据的情况下,基线中下压聚合函数的计算可以下推到微块中直接进行,count(*) 可以直接在过滤结果或者微块行数上面计算。 聚合函数下压可能指的是将聚合操作尽可能下推到数据源更底层的地方执行,比如在数据库的存储引擎或者更靠近数据的位置,而不是在应用层或者查询的后期处理阶段。这样做的目的应该是为了提高查询性能,减少数据传输和处理的开销。 聚合函数用于扫描一组记录,然后返回单行记录,常见的聚合函数有 count()、sum()、avg()、min()、max()。
聚合函数下压的限制 虽然聚合函数下压有显著优势,但其应用也有一定的限制。
依赖数据存储引擎的能力: 只有在存储引擎支持聚合操作的情况下,聚合函数下压才能生效。
复杂聚合的下压可能受限: 一些更复杂的聚合操作(如窗口函数、用户定义函数等)可能无法下压。
涉及多阶段计算(如 DISTINCT + COUNT)或窗口函数(如 ROW_NUMBER())的聚合可能无法下压。
问题的风险及影响
如果命中聚合函数下压相关问题执行性能可能会下降
适用版本
OceanBase 数据库 V4.2.x 版本。
解决方法及规避方式
计划满足聚合函数下压的形式。
physical_range_rows和logical_range_rows比table_rows大很多。控制存储层特性下压级别
_pushdown_storage_level是默认值符合预期的 满足以上三点可以尝试对租户发起合并,合并完成后观察SQL执行耗时和执行计划。