先说几个核心判断：嵌套超过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三层嵌套，而外层那个WHERE条件，压根儿没穿透到底层的基表上去。
怎么判断自己的查询已经触发了这个退化机制？看几个指标就行：
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（PostgreSQL/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的表现可能比原始视图还糟糕。
常见的坑：
- 在CTE定义里写
SELECT *，这会阻止列剪枝，拖慢物化速度，增加page fault的概率。 - 多个CTE交叉引用（比如A依赖B，B又依赖A），会让优化器直接退化成全量物化。
- 中间的CTE如果加了
ORDER BY或LIMIT，会触发排序或截断，后面的查询就无法复用该结果集了。
扁平化关键不在“拆”，而在“可控穿透”
真正有效的扁平化，核心不是把嵌套拆开，而是让优化器能准确估算每一步的行数，并确保外层条件可以穿透到底层基表。一个更可靠的策略是：把最内层的视图替换成等价的子查询先测试一下，这比单纯加WITH更靠谱。
实战建议：
- 优先验证：单拎出最内层的子查询，加上相同
WHERE条件跑一遍，看看它是否走索引，返回的行数是否合理。 - 临时表比CTE更可控：显式
CREATE TEMP TABLE tmp AS SELECT ...，之后手动建索引，这样可以完全避免优化器误判。 - 物化视图只适合那些重复消费且更新频次极低的场景，不是所有嵌套都该去物化。
一句话总结：嵌套层级本身不产生开销，但每多一层，就多一次优化器放弃决策的机会。问题不在于你写了多少层，而在于数据库已经懒得帮你算清楚了。
