嵌套超3层的SQL视图必然导致性能失控，因优化器放弃代价估算与条件下推，表现为EXPLAIN正常但WHERE未下推、预估/实际行数差3个数量级以上、频繁Materialize/Table Spool及physical reads暴增。
嵌套超过3层的SQL视图，优化器基本放弃代价估算和条件下推——这不是配置问题，是结构性失效。
EXPLAIN看起来正常，但实际没下推WHERE条件
你看到执行计划里只有Seq Scan on v_orders_summary，不代表它只扫这一张表。背后可能藏着v_customers_active → v_region_map → customers三层嵌套，而外层WHERE country = 'CN'根本没传到regions表扫描节点。
- 检查
EstimatedRows和ActualRows差距：差3个数量级以上（比如预估100行、实际扫了80万行），就是条件下推失败的铁证 - PostgreSQL中留意
Materialize节点是否高频出现，且耗时占总时间70%+；SQL Server则看执行计划XML里有没有大量Table Spool或未下推的Filter - 用
EXPLAIN ANALYZE加BUFFERS（PG）或SET STATISTICS IO ON（SQL Server），对比physical reads——嵌套视图常让物理读从几千暴增到百万级
子查询在视图里会被展开多次，不是“执行一次”
视图不缓存结果，只是文本模板。当v_active_users引用含子查询的v_user_summary，优化器会把子查询逻辑原样复制粘贴，而不是复用中间结果。
- 例如
(SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id)，在外层过滤后仍被实例化两次：一次算全量用户订单数，一次只算last_login > '2026-01-01'用户的订单数 - 相关子查询触发
DEPENDENT SUBQUERY（MySQL）或Nested Loop（SQL Server/PG），外层10万用户 × 子查询平均500行扫描 = 5000万行IO -
NOT IN遇到NULL值直接整行丢弃，且无法走哈希连接；EXISTS若logins(user_id, login_time)缺复合索引，就只能全表扫
CTE不是自动解药，写错反而更慢
盲目用WITH替代嵌套视图，可能把原本可内联的逻辑强制物化，尤其在PostgreSQL默认行为下。
- 在CTE里写
SELECT *会阻止列剪枝，多余字段拖慢物化速度，增加page fault概率 - 多个CTE交叉引用（A依赖B、B又依赖A）会让优化器退化为全物化，失去线性执行优势
- 中间CTE加
ORDER BY或LIMIT会触发排序或截断，后续无法复用结果集；MySQL 8.0.23之前无MATERIALIZED提示，CTE可能比原视图还慢
扁平化不是加个WITH就行，关键在控制中间结果粒度
真正有效的扁平化，是让优化器能准确估算每一步的行数，并允许外层条件穿透到底层基表。
- 把最内层视图替换成等价子查询测试：如果性能明显提升，说明嵌套就是瓶颈
- 用
WITH时只选必要字段，命名带语义（如recent_orders而非t1），并确保每步只依赖前一步 - 对中间结果建索引：PostgreSQL可加
/*+ Materialize */提示（v14+），SQL Server建议用CREATE MATERIALIZED VIEW或临时表+显式CREATE INDEX
最易被忽略的一点：嵌套超3层后，sp_depends（SQL Server）和pg_depend（PG）基本不可信，依赖链必须人工逐层验证——你以为的“只改了v_b”，可能实际影响v_a → v_c → v_d全部执行路径。
