真正有效的优化是预聚合和物化视图：预聚合按业务维度提前计算汇总结果并增量更新；物化视图由数据库托管刷新，不同数据库实现方式各异；推荐分层设计并严防数据不一致。
面对亿级数据的实时统计需求，直接在原始大表上做 GROUP BY 或复杂聚合查询通常会严重超时或拖垮数据库。真正有效的优化不是靠加索引或调参，而是改变计算范式：把“查时算”变成“算好再查”，核心手段就是预聚合和物化视图。
预聚合：按业务维度提前算好汇总结果
预聚合本质是用空间换时间，在写入或定时任务中，将高频查询所需的聚合结果（如日活、各城市订单总额、商品类目销量TOP10）预先计算并存入轻量汇总表。关键在于匹配真实查询模式。
- 粒度要对齐查询需求：比如前端只看“天粒度+省份+一级类目”，就不要存“小时+城市+三级类目”，避免冗余和维护成本
- 增量更新比全量重建更实用：用
INSERT ... ON CONFLICT UPDATE（postgresql）或MERGE（oracle/SQL Server）按天/小时追加新数据，而非每天 truncate + recompute - 带版本或时间戳字段：例如
stat_date、updated_at，方便核对数据新鲜度和排查延迟
物化视图：数据库原生支持的自动预聚合机制
物化视图（Materialized View）是预聚合的托管升级版——它由数据库管理刷新逻辑、存储物理数据，并可被查询优化器自动识别重写。但不同数据库支持差异大，需按实际选型：
- PostgreSQL：需借助
pg_cron或外部调度触发REFRESH MATERIALIZED VIEW CONCURRENTLY；并发刷新不锁表，适合读多写少场景 - Oracle：支持
FAST REFRESH ON COMMIT，事务提交即同步更新物化视图，一致性最强，但对基表有物化视图日志要求 - clickhouse：用
MATERIALIZED VIEW+ReplacingMergeTree实现近实时流式预聚合，写入即触发计算，延迟常在秒级 - mysql：无原生物化视图，可用触发器+汇总表模拟，或结合 flink CDC 做外部预聚合
组合策略：分层预聚合 + 物化视图降维
单一预聚合表易成性能瓶颈。推荐分层设计：底层宽表 → 中层多维汇总表 → 上层宽口径物化视图。
- 底层保留明细（如用户行为日志），按天分区，只建必要索引
- 中层按业务线建 3–5 张汇总表：如
daily_user_stats（按设备/渠道/地区）、hourly_order_agg（按支付状态/配送方式） - 上层用物化视图封装常用交叉维度，例如 “近7天各省份新老客订单金额对比”，避免每次查询都
JOIN多张汇总表
避坑提醒：别让预聚合变成新负债
预聚合不是银弹，失控反而增加系统复杂度和数据不一致风险。
- 禁止手动修改预聚合表：所有写入必须走统一入口（存储过程/etl任务/物化视图刷新），否则无法保障一致性
- 监控刷新延迟与失败率：比如物化视图刷新耗时突增，可能预示基表膨胀或统计逻辑变慢，需及时干预
- 冷热分离：历史聚合数据（如3年前日活）转入归档库或列存分析引擎（如Doris/StarRocks），主库只留最近6–12个月活跃聚合表