物化视图在PostgreSQL中需满足源表低频更新、查询复杂且读远大于写才真正有用；必须手动刷新，推荐用CONCURRENTLY选项并建唯一索引，且需单独建索引提升查询性能。

物化视图在PostgreSQL里怎么建才真有用

物化视图不是“建了就快”，它本质是一张定期刷新的静态快照。PostgreSQL原生不支持自动刷新，CREATE MATERIALIZED VIEW后必须手动调用REFRESH MATERIALIZED VIEW，否则数据永远停留在创建那一刻。

常见错误是把高频更新的表（比如订单明细）作为物化视图源，结果每次REFRESH锁表几秒，反而拖慢写入。真正适合的场景是：源表变化频率低（如每日维度表）、查询逻辑重（多层JOIN+GROUP BY）、且读远大于写。

• 用CONCURRENTLY选项避免刷新时阻塞读：REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales_summary，但要求物化视图必须有唯一索引
• 别在事务里建或刷新物化视图——它不支持事务内原子性，出错可能留半截脏数据
• 记得给物化视图加索引：CREATE INDEX ON mv_sales_summary (region_id, sale_date)，否则和普通表一样走全表扫描

MySQL没有物化视图，缓存预计算怎么落地

MySQL用户常误以为加个CACHE提示或用QUERY_CACHE（已弃用）就能替代。实际必须自己控制“预计算+缓存”的生命周期。核心思路是：把嵌套JOIN结果写进一张普通表，再用定时任务驱动更新。

关键在更新策略：全量重刷太重，增量难维护。更稳妥的是用时间戳切片——假设源表都有updated_at字段，每次只刷新过去1小时变动的数据，再INSERT ... ON DUPLICATE KEY UPDATE合并到预计算表。

• 预计算表结构要精简：只保留查询真正需要的字段，避免SELECT *带来的IO和内存浪费
• 用pt-online-schema-change工具做预计算表结构变更，防止大表ALTER锁库
• 应用层查的时候，必须显式指定表名（比如FROM sales_summary_cache），不能依赖查询重写或视图代理，否则优化器可能绕过缓存表

嵌套JOIN本身还能怎么剪枝

很多性能问题其实不出在“要不要缓存”，而出在JOIN写法太莽。比如三层嵌套JOIN中，中间层返回10万行，但最终WHERE只取其中200行，却没在中间层加过滤条件。

执行计划里看rows和filtered列最直观：如果某层rows巨大但filtered极低，说明该层缺少有效索引或提前过滤。

• 把能下推的条件尽量写在对应ON子句里，而不是全堆在最后的WHERE——例如JOIN orders o ON o.user_id = u.id AND o.status = 'paid'，比WHERE o.status = 'paid'更能减少连接基数
• 用EXPLAIN FORMAT=JSON看used_columns，确认是否真的用到了索引字段；如果显示NULL，说明索引失效（比如对字段做了函数操作）
• 对超大表关联，考虑用IN (SELECT ...)替代JOIN——当子查询结果集小且稳定时，MySQL优化器有时能走semijoin，比嵌套循环快得多

缓存一致性最容易被忽略的点

预计算表或物化视图一旦引入，最大的坑不是性能，而是数据对不上。业务查到的“最新销量”其实是3小时前的，而客服系统看到的是实时库里的，两边对账直接崩。

没有银弹方案，只有分层控制：对强一致性要求的接口（如支付结果页），绕过所有缓存，直连源表；对分析类查询（如运营日报），接受分钟级延迟，并在接口响应头里明确标出X-Data-Age: 327（单位秒）。

• 别用数据库触发器自动刷新预计算表——高并发写入时容易堆积锁，甚至死锁
• 监控必须覆盖两层：一是预计算任务的执行耗时与失败率（比如Prometheus抓cache_refresh_duration_seconds），二是源表与缓存表关键字段的差异告警（比如COUNT(*)或SUM(amount)偏差超5%）
• 上线前做“影子比对”：新旧查询并行跑，把结果哈希后对比，确认逻辑等价——很多人跳过这步，上线后才发现LEFT JOIN漏掉了NULL分支