嵌套超3层时优化器结构性失效，跳过代价估算并随机选择执行路径，导致执行计划不稳定、预估与实际行数差距巨大、物化节点暴增及I/O飙升。
嵌套超3层时优化器直接放弃代价估算
这不是配置能调的，是结构性失效。MySQL 5.7、SQL Server、PostgreSQL 在嵌套超过3层后，优化器会跳过精确代价估算，随机选择连接顺序和索引路径——你看到的执行计划可能每次都不一样，但EXPLAIN里不会报错或警告。
典型表现：EstimatedRows 和 ActualRows 差距超3个数量级（比如预估120行，实际扫描150万行），说明条件下推完全失败；type=ALL 或 rows 突然暴涨，而单独运行某一层子查询却很快。
- MySQL 5.7 及以前默认不合并视图（view merging），哪怕你只查
v_orders_summary.user_id，也会先执行完整视图定义再过滤 - SQL Server 和 PostgreSQL 虽支持合并，但深层嵌套下常选错驱动表，导致本该走
ref的 JOIN 变成index全扫 - 字段别名模糊、NULL 传播失控、外层
WHERE条件无法下推到底层基表，都是这个阶段的副产物
物化节点暴增拖垮物理 I/O
优化器发现“算不动了”，就退而求其次：把中间结果强制物化。这在 PostgreSQL 中表现为高频 Materialize 节点，在 SQL Server 中是 Table Spool，在 MySQL 中则是隐式临时表。
一旦出现这类节点且耗时占比超70%，基本可锁定为嵌套失控——不是逻辑写得不对，而是数据库被迫用空间换时间，反复读写磁盘。
-
SELECT *在派生表里会阻止列剪枝，导致多余字段被带入物化过程，I/O 和 page fault 指数上升 - CTE 若含
ORDER BY或LIMIT，即使只用一次，也会触发无谓排序，后续无法复用结果集 - 物理 reads 从几千跳到百万级（可通过
EXPLAIN ANALYZE BUFFERS或SET STATISTICS IO ON验证）
相关子查询退化为 N+1 扫描
当嵌套中混入相关子查询（如 WHERE id IN (SELECT ... FROM t2 WHERE t2.x = t1.y)），优化器在深度嵌套下更难识别半连接语义，大概率放弃优化，转为逐行执行内层查询。
此时哪怕 t2.x 有索引，整体复杂度仍是 O(N×M)，而不是理想的 O(N+M)。
- 原句
WHERE customer_id IN (SELECT id FROM customers WHERE status = 'active')应重写为JOIN customers c ON o.customer_id = c.id WHERE c.status = 'active' - 确认改写后
EXPLAIN中type是ref或eq_ref，不是ALL或index - 分库分表场景下，
IN子查询必须改JOIN，且ON条件必须含分片键，否则路由失效
统计信息失真让优化器“瞎猜”
每多一层嵌套，优化器对中间结果行数的估计就越不准。尤其当某层含聚合（如 COUNT(*) GROUP BY user_id）或复杂过滤（如 JSON_CONTAINS），统计信息无法传递，后续 JOIN 或 WHERE 就变成蒙眼配对。
真正卡点不在语法，而在人工验证每层的行数分布与索引命中情况——你得自己跑出各层子查询的 SELECT COUNT(*) 和 EXPLAIN，比对是否和外层预估一致。
- 中间结果超1万行且需多次 JOIN 时，
CREATE TEMPORARY TABLE+ 显式ADD INDEX比 CTE 更可控 - MySQL 8.0.23+ 可用
MATERIALIZED强制物化，但必须配合字段显式声明，SELECT *仍会导致列序错位 - 临时表索引漏建是高频翻车点：没索引的临时表
JOIN就是全表扫描，性能比原嵌套还差
