嵌套查询性能优化应先分析执行计划再决定是否物化，盲目创建物化视图未必提速；需警惕多层 Nested Loop、大表 Seq Scan、Materialize 节点高耗时等典型问题。
嵌套查询太慢，先看执行计划再决定要不要物化
直接加物化视图不等于变快，很多情况下嵌套查询本身就能被优化器重写或下推。先用 EXPLAIN ANALYZE 看清实际执行路径——如果外层只是简单 WHERE 过滤、ORDER BY 或少量 LIMIT，往往没必要物化；真卡在内层聚合 / 连接 / 子查询反复计算上，才值得考虑物化。
常见错误现象：Nested Loop 套多层、Seq Scan 在大表上反复出现、Materialize 节点耗时占比超 60%。
- PostgreSQL 中
MATERIALIZED VIEW不自动刷新，REFRESH MATERIALIZED VIEW是阻塞操作，别在高峰期跑 - Oracle 的物化视图依赖
QUERY REWRITE开关和ENABLE QUERY REWRITE权限，没开就完全不生效 - MySQL 没原生物化视图，用临时表 + 定时
INSERT …… SELECT模拟时，注意事务隔离级别导致读到旧快照
物化视图刷新时机：延迟 vs 一致性必须二选一
实时性要求高就别碰全量刷新，异步增量刷新又受限于数据库能力。PostgreSQL 14+ 支持 CONCURRENTLY 刷新，但要求物化视图有唯一索引；Oracle 的 FAST REFRESH 依赖物化视图日志（MLOG$ 表），没建日志就退化为全量刷。
使用场景：报表类查询可接受分钟级延迟，用定时 REFRESH MATERIALIZED VIEW CONCURRENTLY；订单详情页强一致读，宁愿加 INDEX 和 CLUSTER，也别让应用读到过期物化结果。
- PostgreSQL 刷新时若没加
CONCURRENTLY，会锁住整个物化视图，所有查询阻塞 - Oracle 物化视图日志需在基表上显式创建，且只对
INSERT/UPDATE/DELETE生效，TRUNCATE会导致增量失效 - 物化视图定义里含
NOW()、CURRENT_DATE等不稳定函数，会导致无法增量刷新
嵌套查询改写为物化视图前，先确认是否能用 CTE 或窗口函数替代
很多“嵌套”其实只是逻辑分层，不是性能瓶颈。比如带 ROW_NUMBER() OVER (PARTITION BY ……) 的排名、用 WITH RECURSIVE 展开树形结构，这些比建物化视图更轻量、更可控。
参数差异：WITH CTE 默认不物化（PostgreSQL 12+ 可加 MATERIALIZED 关键字强制物化），而 Oracle 的 WITH 子句加 /*+ MATERIALIZE */ 提示才可能落地中间结果。
- CTE 被多次引用时，PostgreSQL 默认重复执行，不是“缓存”，除非显式写
WITH my_cte AS MATERIALIZED (SELECT ……) - SQL Server 的
OPTION (RECOMPILE)有时比物化更能应对参数嗅探导致的嵌套低效 - 含
GROUP BY+HAVING的嵌套，优先检查是否缺复合索引，而不是急着物化
物化视图的索引和统计信息容易被忽略
新建的物化视图默认没索引，也没统计信息，查询计划可能继续走错路。PostgreSQL 中 ANALYZE 必须手动跑一次，否则优化器按默认行数估算；Oracle 需要 DBMS_STATS.GATHER_TABLE_STATS 显式收集。
性能影响：没索引的物化视图在 JOIN 或 WHERE 过滤时，照样触发全表扫描；统计不准则可能导致嵌套查询中物化视图被当作小表驱动大表，实际却是千万级。
- PostgreSQL 物化视图上建索引语法和普通表一致：
CREATE INDEX ON my_mv (col1, col2) - Oracle 物化视图的统计信息要单独收集，基表的统计信息不会自动同步过去
- 物化视图字段名若和基表冲突（如都叫
id），在嵌套查询中必须用别名限定，否则报column reference "id" is ambiguous
物化视图不是银弹，它把计算成本从查询时挪到了刷新时，而刷新的代价、延迟、一致性边界，常常比嵌套查询本身更难掌控。
