嵌套超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' 后，它仍会被实例化两次：一次算全量用户订单数，一次只算活跃用户的订单数。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 相关子查询触发
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 ...，再手动建索引，避免优化器误判 - 物化视图只适合重复消费 + 低更新频次场景，不是所有嵌套都该物化
嵌套层级本身不产生开销，但每多一层，就多一次优化器放弃决策的机会——问题不在你写了多少层，而在数据库已经懒得算清楚了。
