为何SQL查询中嵌套层数过多会导致执行计划失效

嵌套超3层时优化器直接放弃代价估算和条件下推，是数据库内核的硬性退化策略；表现为预估/实际行数差3个数量级以上、MATERIALIZE/Table Spool高频出现、WHERE条件无法穿透到底层基表。

嵌套超3层时优化器直接放弃代价估算

这不是配置能调的，是数据库内核对嵌套结构的硬性退化策略。PostgreSQL、SQL Server、MySQL 在嵌套超过3层后，会跳过精确行数估算和条件下推逻辑——它不再尝试把 WHERE country = 'CN' 推到最底层的 regions 表扫描节点，而是按“最坏情况”生成计划。

典型表现：EXPLAIN ANALYZE 显示 Seq Scan on v_orders_summary，但实际背后展开的是 v_customers_active → v_region_map → customers 三层嵌套，且外层条件完全没穿透到底层基表。

• 检查 EstimatedRows 和 ActualRows：差3个数量级以上（比如预估100行、实际扫80万行），就是代价估算崩了
• PostgreSQL 看 MATERIALIZE 节点是否高频出现，耗时占比 >70%
• SQL Server 看执行计划 XML 中是否有大量 Table Spool 或未下推的 Filter

子查询在视图里会被原样复制粘贴，不是执行一次

视图不是缓存结果，只是文本模板。当 v_active_users 引用含子查询的 v_user_summary，优化器会把子查询逻辑完整复制进每一处调用位置，而不是复用中间结果。

例如这个子查询：(SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id)，在外层加了 WHERE last_login > '2026-01-01' 后，它仍会被实例化两次：一次算全量用户订单数，一次只算活跃用户的订单数。

• 相关子查询触发 DEPENDENT SUBQUERY（MySQL）或 Nested Loop（PG/SQL Server），外层10万行 × 子查询平均500行 = 5000万行IO
• NOT IN 遇到 NULL 值直接整行丢弃，且无法走哈希连接
• EXISTS 若 logins(user_id, login_time) 缺复合索引，就只能全表扫

CTE不是自动解药，写错反而更慢

盲目用 WITH 替代嵌套视图，可能把原本可内联的逻辑强制物化。PostgreSQL 默认行为下，CTE 就是物化步骤；MySQL 8.0.23 之前没有 MATERIALIZED 提示，CTE 可能比原视图还慢。

• SELECT * 写在 CTE 定义里会阻止列剪枝，拖慢物化速度，增加 page fault 概率
• 多个 CTE 交叉引用（A依赖B、B又依赖A）会让优化器退化为全物化
• 中间 CTE 加 ORDER BY 或 LIMIT 会触发排序或截断，后续无法复用结果集

扁平化关键不在“拆”，而在“可控穿透”

真正有效的扁平化，是让优化器能准确估算每一步的行数，并允许外层条件穿透到底层基表。把最内层视图替换成等价子查询测试，比单纯加 WITH 更可靠。

• 优先验证：单拎出最内层子查询，加相同 WHERE 条件跑一遍，看是否走索引、返回行数是否合理
• 临时表比 CTE 更可控：显式 CREATE TEMP TABLE tmp AS SELECT ...，再手动建索引，避免优化器误判
• 物化视图只适合重复消费 + 低更新频次场景，不是所有嵌套都该物化

嵌套层级本身不产生开销，但每多一层，就多一次优化器放弃决策的机会——问题不在你写了多少层，而在数据库已经懒得算清楚了。