视图嵌套超过3层必然导致性能失控，因优化器放弃代价估算、谓词无法下推、执行计划随机漂移；判断依据是WHERE未下推、预估/实际行数差3个数量级、频繁出现Materialize或Table Spool。
视图嵌套超过3层，性能不是“可能慢”，而是必然失控——优化器放弃代价估算、谓词无法下推、执行计划随机漂移，加索引或调参数都救不回来。
怎么看是不是视图嵌套惹的祸？
别只信EXPLAIN表面看起来“正常”，重点抓三类铁证：
- 外层加了
WHERE country = 'CN'，但执行计划里regions表扫描节点没出现这个过滤条件——说明条件下推彻底失败 -
EstimatedRows和ActualRows差3个数量级以上（比如预估100行，实际扫80万行） - PostgreSQL里高频出现
Materialize节点且耗时占比＞70%；SQL Server里大量Table Spool (Eager Spool)或执行计划XML中反复出现Filter未下推
用CTE展平视图链，但必须避开三个致命写法
CTE不是语法糖，写错反而比原视图还慢。关键在控制中间结果粒度，让优化器能看清数据流：
- 禁止在CTE里写
SELECT *——多余列会阻止外层WHERE下推到基表，尤其后续有JOIN时 - 禁止多个CTE交叉引用（比如
A依赖B，B又依赖A）——优化器退化为全物化，失去线性优势 - 禁止在中间CTE里加
ORDER BY或TOP（SQL Server）/LIMIT（PG/MySQL）——触发排序或截断，后续无法复用结果集
正确示例（SQL Server）：
WITH region_map AS ( SELECT region_id, country FROM regions WHERE active = 1 ), customers_active AS ( SELECT c.id, c.name, r.country FROM customers c INNER JOIN region_map r ON c.region_id = r.region_id ), orders_summary AS ( SELECT o.order_id, ca.country, COUNT(*) cnt FROM orders o INNER JOIN customers_active ca ON o.customer_id = ca.id GROUP BY o.order_id, ca.country ) SELECT * FROM orders_summary WHERE country = 'CN';
什么时候该建临时表，而不是硬扁平？
物化不是“加速单次查询”的银弹，它解决的是重复消费+低更新频次场景：
- 该中间结果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得靠CREATE TEMPORARY TABLE+调度任务
真正难的不是拆开嵌套，而是判断哪一层该留作逻辑分界、哪一层该物化——这取决于它是否被多个下游共享，以及基表更新节奏是否允许延迟。盲目物化小结果集，反而增加I/O和维护负担。
