为什么SUM统计会慢
直接对明细表做SUM聚合，尤其是跨大时间范围或关联多张表时，数据库要扫描大量行、计算每条记录的值，再汇总。如果没建好索引、字段没走索引、或者数据量上亿，SUM就容易卡住。不是函数本身慢，而是它背后触发的全表扫描或低效连接拖慢了整体响应。
预聚合表的核心思路
把“每次查都要算”的逻辑，变成“提前算好、存起来、查时直接取”。比如按天/按客户/按产品维度，预先算好销售额总和、订单数、平均单价等指标，存在一张独立的汇总表里。查询时只扫几千行聚合表，而不是几百万行明细表。
- 聚合粒度要匹配常用查询条件（如常按“日期+门店”查，就按这两个字段分组预计算）
- 聚合字段尽量覆盖高频SUM、COUNT、AVG等，避免重复加工
- 用定时任务（如每天凌晨）或触发器/消息队列实时更新，保证数据不过期
怎么建一张高效的预聚合表
以销售明细表sales_detail为例，常用查询是“查某月各门店销售额总和”，可建如下预聚合表：
CREATE TABLE sales_daily_store AS SELECT DATE(created_at) AS stat_date, store_id, SUM(amount) AS total_amount, COUNT(*) AS order_cnt FROM sales_detail GROUP BY DATE(created_at), store_id;
关键点：
- 主键或联合索引建在(stat_date, store_id)上，让点查极快
- 如果还要支持“某门店近7天趋势”，加一个stat_date单独索引
- 避免在预聚合表里留冗余字段（如商品名、用户地址），只存聚合结果和分组键
查询时如何无缝切到预聚合表
业务SQL不改逻辑，只换表名或用视图兜底。推荐两种方式：
- 视图路由：建一个v_sales_summary视图，内部判断参数时间范围——近7天走预聚合表，历史数据走明细表UNION ALL（冷热分离）
- 应用层开关：在报表服务里加配置项，比如use_pre_agg=true时自动拼预聚合表SQL，否则走原逻辑
- 注意预聚合表的NULL值和明细表一致性（比如未支付订单是否计入），需在ETL阶段明确清洗规则
