视图嵌套超3层必然失控，因MySQL 5.7前不合并、SQL Server/PostgreSQL优化器放弃代价估算，导致条件下推失效、执行计划漂移；CTE盲目替换反加重负担，需避SELECT *、交叉引用、中间ORDER BY/LIMIT；物化视图仅适用于高频复用、低更新、高逻辑读节省场景；优先用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）
用 CTE 替代嵌套视图的三个高危写法
CTE 不是“嵌套子查询的美化语法”，盲目替换反而加重负担。PostgreSQL 默认可能强制物化 CTE，而原嵌套视图反而支持条件下推。
必须避开这些坑：
- 在 CTE 定义里写
SELECT *—— 多余列会阻止外层WHERE下推到基表 - 让多个 CTE 交叉引用（比如 A 依赖 B，B 又依赖 A）—— 打破线性执行顺序，优化器可能退化为全物化
- 在中间 CTE 里加
ORDER BY或LIMIT—— 触发排序或截断，后续无法复用结果集
MySQL 8.0.23+ 之前没有 MATERIALIZED 提示，此时用 CTE 替代视图，可能把原本可内联的逻辑锁死成物化步骤。
什么时候该建物化视图，而不是继续扁平化
物化不是“加速单次查询”的银弹，它解决的是重复消费 + 低更新频次场景。判断标准很具体：
- 该中间结果在 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 得靠临时表 + 调度任务
优先用 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+ 窗口函数或聚合子查询 - 用
IN (SELECT ...)做大批量匹配 → 改用JOIN或EXISTS，尤其当子查询返回行数 > 数千时
运行 EXPLAIN ANALYZE 对比改写前后，重点看是否真正减少了嵌套层级与扫描行数。别信“看起来更清晰”——执行路径没变，只是换了个写法而已。
