视图嵌套超3层必然失控，因MySQL 5.7前不合并、SQL Server/PostgreSQL优化器放弃代价估算，导致条件下推失效、执行计划漂移；应优先用JOIN/EXISTS替代非必要嵌套。
视图嵌套超3层就该停手
不是“可能慢”，是必然失控。MySQL 5.7 及以前默认不合并视图，SQL Server 和 PostgreSQL 在嵌套超三层后，优化器会放弃代价估算，导致条件下推失效、执行计划随机漂移。你看到 EXPLAIN 显示 Seq Scan on orders，不代表它真只扫了 orders——很可能这扫描发生在第4层子视图里，而外层 WHERE country = 'CN' 根本没下推过去。
典型症状包括：
-
rows估算从百级跳到百万级 - 执行计划里突然多出
Materialize节点，且耗时占总时间 70%+ - 同一查询在不同时间生成完全不同的计划（比如有时走
Nested Loop，有时变Hash Join）
用 JOIN / EXISTS 替代非必要嵌套
很多深层嵌套源于习惯性写法，而非业务必需。例如：
- 用
(SELECT COUNT(*) FROM orders) > 0判断存在性 → 改用EXISTS (SELECT 1 FROM orders) - 用子查询关联单字段（如
SELECT u.name, (SELECT MAX(o.created_at) FROM orders o WHERE o.user_id = u.id)）→ 改为LEFT JOIN (SELECT user_id, MAX(created_at) AS max_created FROM orders GROUP BY user_id) o ON u.id = o.user_id
注意：改写后必须检查 JOIN 字段是否有索引。若 orders.user_id 缺失索引，LEFT JOIN 仍会触发全表扫描；联合索引应按驱动表顺序建，比如外层是 users，内层 orders 上就要建 INDEX(user_id, status) 而非仅 INDEX(user_id)。
CTE 不是万能解药，盲目替换反而加重负担
WITH CTE 不是“嵌套子查询的美化语法”。PostgreSQL 默认可能强制物化 CTE，而原嵌套视图反而支持条件下推；MySQL 8.0.23+ 之前没有 MATERIALIZED 提示，此时用 CTE 替代视图，可能把原本可内联的逻辑锁死成物化步骤。
必须避开这些坑：
- 在 CTE 定义里写
SELECT *—— 多余列会阻止外层WHERE下推到基表 - 让多个 CTE 交叉引用（比如 A 依赖 B，B 又依赖 A）—— 打破线性执行顺序，优化器可能退化为全物化
- 在中间 CTE 里加
ORDER BY或LIMIT—— 触发排序或截断，后续无法复用结果集
物化视图只适用于特定高频复用场景
物化不是“加速单次查询”的银弹，它解决的是重复消费 + 低更新频次场景。判断标准很具体：
- 该中间结果在 24 小时内被 ≥5 个不同业务查询调用，且每次过滤字段差异大（比如一个查
WHERE status = 'paid'，另一个查WHERE created_at > '2026-04-01'） - 其基表数据变更频率 ≤ 每小时 1 次，且物化后能减少 ≥70% 的逻辑读（用
EXPLAIN (ANALYZE, BUFFERS)对比验证） - 你愿意承担调度成本：
SQL Server需CREATE MATERIALIZED VIEW+ 定时REFRESH；PostgreSQL用CREATE MATERIALIZED VIEW+REFRESH MATERIALIZED VIEW CONCURRENTLY；MySQL得靠临时表 + 调度任务
真正容易被忽略的是：物化视图的刷新时机和一致性边界。一旦业务要求“强实时”，哪怕延迟 1 秒都不允许，那它就根本不该出现。
