物化视图提速需显式启用查询重写，rollup须严格按业务维度层级设计，clickhouse物化视图应避免高基数列入order by，预聚合需谨慎处理null及grouping标识以保障指标准确。
物化视图不是“加个索引”就能提速
直接建物化视图却没开启查询重写（QUERY REWRITE），等于把预计算结果锁进保险箱却不给钥匙。Oracle、PostgreSQL（通过pg_cron+物化表模拟）、以及ClickHouse的MATERIALIZED VIEW都要求显式启用重写能力，否则优化器根本不会考虑用它替代原始SQL。常见错误是只执行了CREATE MATERIALIZED VIEW，却漏掉ALTER MATERIALIZED VIEW ... ENABLE QUERY REWRITE（Oracle）或没在查询中命中物化视图的SELECT模式（ClickHouse要求源表名、列名、聚合函数完全匹配）。
ROLLUP预聚合必须对齐业务维度层级
比如销售分析中“年→季度→月→日”是天然层级，但若把city和product_category硬塞进同一个ROLLUP(year, city, product_category)，会导致大量无意义的中间聚合（如“2024年所有城市所有品类”的小计），既浪费存储又拖慢刷新。正确做法是按语义分组：时间维度单独ROLLUP，地理与产品维度用CUBE或GROUPING SETS控制组合爆炸。真实生产中，我们曾因错用ROLLUP让物化视图刷新耗时从8分钟涨到57分钟——问题就出在把非层次字段混入了ROLLUP列表。
ClickHouse物化视图要避开ORDER BY陷阱
ClickHouse的MATERIALIZED VIEW底层是自动触发的INSERT SELECT，如果目标表用MergeTree且ORDER BY里包含高基数列（如user_id），会导致每个新分区排序开销剧增。实操建议：
- 目标表
ORDER BY只保留低基数、高频过滤字段（如event_date, region） - 聚合逻辑尽量下沉到物化视图定义中，避免在查询时再
GROUP BY user_id - 用
ReplacingMergeTree替代MergeTree处理重复数据，防止物化视图因去重逻辑失效而返回脏数据
ORDER BY (user_id, event_time)导致ReplacingMergeTree无法正确去重。
预聚合后NULL值处理会悄悄破坏占比类指标
当物化视图里做了SUM(sales)和COUNT(*)，但原始数据存在sales IS NULL行时，SUM会忽略它们，而COUNT(*)仍会计数，导致后续算“销售额占比”时分母失真。更隐蔽的是，Oracle物化视图默认不物化GROUPING标识列，一旦业务需要区分“真实空值”和“聚合占位符”，就必须显式在物化视图定义中加上GROUPING(region)并建立对应索引。这点在做同比/环比或交叉分析时极易被忽略，最后报表里突然冒出一堆100%占比的异常行，追查半天才发现是物化视图没带GROUPING上下文。
