物化视图预计算高频聚合可提升性能10倍以上，需注意刷新策略与索引；避免SELECT *及大字段拖累I/O；近似算法可平衡精度与响应；务必验证分区裁剪是否生效。
用物化视图预计算高频聚合
当分析需要固定维度（如按天/按地区/按用户等级）反复统计时，实时 GROUP BY + SUM() 会持续拖慢查询。物化视图把结果存成物理表，查询直接走索引扫描，性能提升常达 10x 以上。
注意点：
- PostgreSQL 需用
CREATE MATERIALIZED VIEW+ 定期REFRESH MATERIALIZED VIEW；MySQL 不原生支持，得用普通表 + 应用层定时任务或触发器维护 - 刷新频率要权衡：太频繁加重写压力，太稀疏导致数据滞后；日志类场景通常设为每小时刷新一次
- 务必在物化表的分组字段上建索引，比如
CREATE INDEX ON sales_by_day (date)
避免 SELECT * + 大字段拖垮分析链路
分析查询若包含 TEXT、JSONB 或 BLOB 字段，即使不参与计算，也会强制数据库读取、传输、序列化整块数据，显著放大 I/O 和网络开销。
实操建议：
- 明确只
SELECT真正用于计算或展示的列，尤其是聚合前先WHERE过滤行数 - 对大字段单独建宽表或归档表，主分析表只保留键值和轻量指标
- 用
pg_stat_io（PG）或SHOW PROFILE（MySQL）确认是否因大字段导致read_time异常升高
用近似算法换精度保响应时间
当“大致准确”即可满足业务判断（如 UV 估算、长尾分布观察），硬算精确去重或分位数代价极高。PostgreSQL 的 approx_count_distinct()（需安装 hyperloglog 扩展）、MySQL 8.0+ 的 APPROX_COUNT_DISTINCT() 可将内存占用压到 KB 级，误差率通常
适用边界：
-
COUNT(DISTINCT user_id)表记录超千万时，优先试APPROX_COUNT_DISTINCT(user_id) -
PERCENTILE_CONT(0.95)在大数据集上极慢，改用tdigest_percentile()（PG 扩展）或采样后计算 - 禁止在财务对账、审计溯源等强一致性场景使用近似函数
分区裁剪失效是性能滑坡的隐形推手
按时间分区的表，如果 WHERE 条件里用了函数包裹分区键（如 WHERE DATE(created_at) = '2024-06-01'），优化器无法识别可裁剪的分区，会全表扫描所有分区——哪怕只查一天数据。
必须检查并修正：
- 把
DATE(created_at)改成范围查询：created_at >= '2024-06-01' AND created_at - 确保分区键类型与查询条件类型一致，避免隐式转换（如
created_at::date = '2024-06-01'同样失效） - 用
EXPLAIN确认执行计划中出现Partition Filter: (part_key >= ...)，而非Partition Filter: (true)
实际调优中最容易被忽略的是分区裁剪是否真正生效——它不报错、不告警，只默默让查询变慢几倍甚至几十倍。每次加新分析逻辑前，先看一眼 EXPLAIN 输出里的分区过滤项。
