大家好，我是数据库小学妹👋我踩过的坑，你别再踩。去年帮一个零售客户看经营日报。这是一套典型的 OLAP 数据库报表。按大区、品类、月份汇总，跑一次四十秒。业务要求压到五秒以内。

我第一反应是加索引。看了执行计划才发现，索引帮不上忙。这条查询扫了九个月明细，过滤掉的行只有一成左右。走索引反而更慢。这篇文章把那次排查完整拆一遍。方法不复杂，难的是每一步都别跳。
![tencent-olap-five-steps.png](https://developer.qcloudimg.com/http-save/yehe-12362123/5efdabf3f84beec9495a6e30adeaef48.png)
::: center  
图1：OLAP 报表优化的五个步骤
:::

## 第一步：先判断它是不是 OLAP 数据库负载

不是所有慢查询都叫 OLAP。先看三件事：扫描行数、聚合方式、并发形态。下面这条 SQL，是那张日报的简化版。表名和数据都做了脱敏。用通用 SQL 示意，不同产品语法略有差异。

```
EXPLAIN (ANALYZE, BUFFERS)
SELECT region,
       category,
       date_trunc('month', order_date) AS mon,
       SUM(amount) AS sales,
       COUNT(DISTINCT order_id) AS orders
FROM dwd_order_detail
WHERE order_date >= DATE '2026-01-01'
  AND order_date <  DATE '2026-10-01'
GROUP BY region, category, mon
ORDER BY mon, sales DESC;
```
看几个点。Seq Scan 说明在扫全表。rows 估算和 actual rows 差太多，统计信息可能过期。Buffers 里的 shared read 很大，说明数据不在缓存。Sort 或 Hash 出现 temp spill，说明内存不够。这条查询扫了九个月明细，过滤后还剩九成。典型的 OLAP 数据库负载：大范围扫描、多维聚合、低并发。索引不是第一杠杆。先把扫描量和计算量降下来，再谈索引。

执行计划不用每个字段都看。我重点看四个数。第一个，actual rows。它和 rows 估算差得远，说明统计信息不准。第二个，loops。嵌套循环执行了多少次，次数一高，代价就上去了。第三个，buffers。shared hit 高是好事，shared read 高说明在啃磁盘。第四个，temp read/written。出现临时文件，说明排序或哈希落盘了。这四个数看完，基本能判断慢在扫描、连接、排序还是内存。方向对了，再改 SQL。

## 第二步：OLAP 数据库建模，先决定宽表还是星型

分析型建模有两条常见路线。宽表把常用维度提前拼好，查询路径短。星型模型保留事实表和维度表，灵活，但 join 多。先看差别，再决定用哪条。

|方案|查询路径|适合|代价|
|:-:|:-:|:-:|:-:|
|宽表|单表扫描，少 join|固定报表、高频查询|冗余多，更新和回刷成本高|
|星型|事实表加维度表|即席分析、维度多变|join 多，依赖优化器|
|预聚合表|直接读汇总结果|高频固定报表|粒度难改，回刷麻烦|

我的做法是分层。明细层保留星型，宽表层按报表需求拼。固定日报再往上做预聚合。三层各干各的活，别混在一起。分层的好处是边界清楚。明细层负责灵活，宽表层负责查询路径，预聚合层负责速度。出问题的时候，也知道该查哪一层。

## 两个小动作，先把计算量降下来

在动架构之前，有些 SQL 层面的动作可以先做。第一个，过滤条件尽量前置。能先在明细层过滤的，别等到聚合后再过滤。扫描量少一半，后面所有步骤都轻。第二个，少用高基数列做 COUNT(DISTINCT)。去重计数很吃内存。业务能接受近似值，就用近似聚合；不能接受，再考虑预计算。这两个动作不改变架构，但能先把最贵的那部分计算削掉。别小看这一步，很多报表优化到这里就已经够用了。

## 第三步：OLAP 数据库的分区和排序键，决定扫描量

OLAP 数据库的查询最怕扫全表。分区裁剪是第一道闸。分区键选错，后面的索引和预聚合都白搭。先看报表怎么过滤，再定分区字段。

```
CREATE TABLE dwd_order_detail (
  order_id      BIGINT,
  order_date    DATE,
  region        VARCHAR(32),
  category      VARCHAR(64),
  channel       VARCHAR(32),
  amount        NUMERIC(18,2),
  status        SMALLINT
) PARTITION BY RANGE (order_date);

CREATE TABLE dwd_order_detail_2026_09
  PARTITION OF dwd_order_detail
  FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
```
按月分区，查询带上 order_date 范围，优化器就能裁掉无关分区。上面那条日报查询只碰九个月。分区之后，扫描量直接降一个量级。KES 的分区表也是这个用法。范围分区建好，查询带上时间条件，裁剪才会生效。排序键或聚簇键怎么选？看过滤和分组的高频列。大区、品类经常一起出现，就放在前面。别把低基数列放第一位。有个细节容易忽略。分区太多，元数据和小文件会拖慢规划。按月够用就别按天。我见过按小时分区的表，规划时间比执行时间还长。

## 第四步：OLAP 数据库的预聚合，把重复计算提前做掉

OLAP 数据库的固定日报，每天算同样的口径。与其每次扫明细，不如提前算好。预聚合就是把这份重复计算挪到刷新任务里。算一次，查很多次。

```
CREATE TABLE dws_sales_mon (
  mon        DATE,
  region     VARCHAR(32),
  category   VARCHAR(64),
  sales      NUMERIC(18,2),
  orders     BIGINT,
  updated_at TIMESTAMP,
  PRIMARY KEY (mon, region, category)
);
```
刷新 SQL 如下。用 upsert，保证重复跑不会产生重复行。增量刷新也要能重跑，不能怕补数。口径变了，先改汇总逻辑，再重刷历史。

```
INSERT INTO dws_sales_mon (mon, region, category, sales, orders, updated_at)
SELECT date_trunc('month', order_date)::date AS mon,
       region,
       category,
       SUM(amount),
       COUNT(DISTINCT order_id),
       now()
FROM dwd_order_detail
WHERE order_date >= DATE '2026-09-01'
  AND order_date <  DATE '2026-10-01'
GROUP BY 1, 2, 3
ON CONFLICT (mon, region, category)
DO UPDATE SET sales = EXCLUDED.sales,
              orders = EXCLUDED.orders,
              updated_at = EXCLUDED.updated_at;
```
刷新策略有三种：全量重算、按分区重算、增量合并。日报这种，按天或按月重算最稳。增量合并快，但要处理迟到数据和重复消费。预聚合的粒度别太细。按小时、按素材、按位置全算一遍，表会膨胀得很快。先统计业务真正会查的组合，再决定算哪些。固定口径的汇总，KES 可以直接用物化视图承载。刷新跟着调度走，报表只读汇总结果。

预聚合也不是随便建一张汇总表。OLAP 数据库的预聚合，我一般分三层。DWD 层放明细，保留最细粒度。DWS 层按主题做轻度汇总。ADS 层直接服务报表。这样分层的好处是，口径只在一层定义。报表变了，改 ADS；明细要补，回 DWD。别让每个报表各自写一套聚合 SQL。

分层也有代价。链路长了，数据延迟会增加。刷新顺序要排好，先 DWD，再 DWS，最后 ADS。我见过把三层压成一张宽表的项目。前期快，后期改一个口径，牵一发动全身。

## 第五步：OLAP 数据库报表的验证，别只看一次查询

OLAP 数据库报表改完要验证。我的做法是同一份数据、同一台机器、同一并发。跑三组：改前、加分区后、加预聚合后。三组数据放在一起，才知道每一步到底省了多少。

|阶段|扫描行数|峰值内存|响应时间|备注|
|:-:|:-:|:-:|:-:|:-:|
|改前|约 1.1 亿|3.2 GB|40 s|全表扫描，排序落盘|
|加分区|约 1800 万|1.1 GB|12 s|只扫 9 月分区|
|加预聚合|约 3 千|80 MB|2 s|直接读汇总表|

这组数字是我为了讲清楚搭的示意环境。单机 8 核 32G，数据做了脱敏。换机器、换数据量，数字会变。方法不变。除了单次查询，还要看并发和刷新窗口。十个报表同时跑，预聚合表也可能被打满。刷新任务别和业务高峰撞在一起。
![tencent-olap-40s-to-2s.png](https://developer.qcloudimg.com/http-save/yehe-12362123/cc896dcc0757ae3c97c4a78d81267d5c.png)
图2：同一张日报在三个阶段的变化（脱敏示意）

成本也要摊开看。我把三类方案的账列在一起。存储只是第一笔，计算和刷新也要算。很多方案输在后两项。

|方案|存储成本|计算成本|刷新成本|维护成本|
|:-:|:-:|:-:|:-:|:-:|
|宽表|中，冗余多|低，查询路径短|中，更新要回刷|低，一张表|
|星型|低，规范化|高，join 多|低，明细不动|中，模型要维护|
|预聚合|高，多一份结果|低，直接读结果|高，粒度和回刷|中高，多一层链路|
|融合库（KES）|中，同库多一份结果|中，共享资源要隔离|中，物化视图要调度|中，少一套链路，多一层治理|

这张表没有标准答案。数据量、并发、新鲜度不同，权重就不同。先算清楚自己最在意哪一项。别人的最优解，放到你这里未必成立。

## 国产化项目里的一个变体

后来这个客户做国产化替换。交易库迁到了金仓（KingbaseES）。分析侧保留了独立的报表库。有人问我，为什么不把分析也一起放进去。我的回答是：看负载。它的分区表能按时间裁掉无关数据。统计信息维护也能稳住执行计划。非核心看板放进去，跑得动。但核心交易要稳，分析负载又经常突发，先分开更稳。

融合架构可以把一部分分析收进来。我们只放了非核心的看板，核心日报仍然走独立分析库。这个边界，是我从前面那次四十秒里学到的。工具能收，不代表该全收。先看负载，再看架构。

## 三条避坑经验

第一条，预聚合粒度别按“能想到”来。按“业务真的会查”来。粒度越细，回刷越慢，存储越贵。第二条，分区键别乱选。按时间分区最通用，但查询如果不带时间条件，分区裁剪就失效。设计之前，先看报表的过滤条件。第三条，别只看单次查询快不快。并发、刷新窗口、数据延迟，都要一起算。

我最早只盯着响应时间，结果预聚合任务每天凌晨跑三个小时。后来改成按分区重算，才压到二十分钟。这个教训，比任何调优参数都值钱。现在我把这条写进了验收清单。

## 什么时候不该预聚合

预聚合不是万能药。三种情况，我会劝你先别上。第一种，查询维度天天变。今天按渠道，明天按门店，后天按活动。你预聚合不过来。第二种，明细要看到每一行。预聚合只有汇总，下钻不了。第三种，数据延迟要求很高。预聚合要等批处理，实时性天然吃亏。这几种情况，保留明细、做好分区和列存，往往比硬做预聚合更稳。

## 几个常被问的问题

**OLAP 数据库报表一定要预聚合吗？** 不一定。查询频率低、维度多变，保留明细更灵活。高频固定报表才值得预聚合。**宽表和星型模型怎么选？** 固定报表多，宽表省事。即席分析多，星型更灵活。很多团队是两层都留。

**分区越多越好吗？** 不是。分区太多会拖慢规划和元数据管理。按业务查询粒度选，按月够用就别按天。**预聚合表怎么处理迟到数据？** 按时间分区重算最稳。增量合并要留出回刷窗口，别假设数据一定准时到。

## 写在最后

OLAP 数据库的报表优化，顺序很重要。先判断负载，再建模，再分区，最后才预聚合。跳过前面几步，直接上预聚合。往往会得到一张又大又难维护的表。这也是我看 KES 这类融合数据库的角度。它用物化视图接固定口径，用并行查询分担临时分析。两类负载能少搬一次。但前提还是那句话：负载先分清，模型先理好。少搬一次是结果，不是起点。

你们报表优化时，最先动的是索引还是建模？评论区聊聊。别急着换引擎，先把路线说清楚。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


大家好，我是数据库小学妹👋我踩过的坑，你别再踩。去年帮一个零售客户看经营日报。这是一套典型的 OLAP 数据库报表。按大区、品类、月份汇总，跑一次四十秒。业务要求压到五秒以内。

OLAP数据库报表优化：日报40秒压不下来？5步降到2秒

一张经营日报从40秒压到2秒的排查记录。按“判断负载—宽表建模—分区裁剪—预聚合—验证”五步走，附EXPLAIN ANALYZE、建表SQL、刷新SQL和前后对比表，最后给出三条避坑经验，并落到金仓 KES 的分区、物化视图与验证做法。

数据库

OLAP报表从40秒优化到2秒，关键不在索引而在于负载判断、分层建模、分区裁剪和预聚合四步。本文用真实案例拆解全套流程，涵盖执行计划分析、宽表与星型模型选择、分区键设计、预聚合策略及成本对比，并给出避坑建议，助你快速定位报表性能瓶颈。

数据管理

代码解释

OLAP

让每一个 Agent，都跑在云上

tchousep

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OLAP数据库报表优化：日报40秒压不下来？5步降到2秒-腾讯云开发者社区-腾讯云

OLAP数据库报表优化：日报40秒压不下来？5步降到2秒

OLAP数据库报表优化：日报40秒压不下来？5步降到2秒

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐