多层嵌套查询导致优化器基数估计结构性失准，嵌套≥4层时主流数据库退化为启发式估算，条件无法下推、统计信息失效、三值逻辑放大误差，使执行计划严重偏离实际。
多层嵌套查询不是“写得复杂才慢”，而是直接让优化器的基数估计（Cardinality Estimation）在第一层就失准，后续所有代价计算全盘失效——这不是参数或统计信息能调回来的，是结构性崩塌。
嵌套超3层时优化器主动放弃精确估算
SQL Server、PostgreSQL 和 MySQL 8.0+ 在嵌套深度 ≥4 层时，会退化为启发式估算或直接沿用上层粗略值。比如一个 SELECT * FROM (SELECT * FROM (SELECT * FROM users WHERE status = 'active') t1) t2，外层 WHERE t2.id > 1000 几乎无法下推到最内层基表扫描节点，导致 EstimatedRows 常固定为 100 或 1000 这类默认值，而实际返回可能是 5 万行。
- MySQL 5.7 及更早版本完全不支持视图合并，嵌套视图哪怕只取一个字段，也会先执行完整子树再过滤
- PostgreSQL 中 CTE 若含
ORDER BY或LIMIT，会强制物化，切断条件穿透路径 - SQL Server 的 CE 模型对嵌套子查询缺乏直方图继承机制，只能靠单列统计硬猜多维分布
NOT IN / EXISTS 类子查询天然放大误差
NOT IN 子查询只要涉及允许 NULL 的列，优化器就无法准确建模三值逻辑（TRUE/FALSE/UNKNOWN），常把整个谓词估算为“几乎不匹配”，导致误选 Nested Loop 而非 Hash Join；EXISTS 虽语义清晰，但若子查询本身没走索引，优化器会按“全表扫一次”估算成本，而实际可能因缓存或分区剪枝快得多。
-
WHERE user_id NOT IN (SELECT user_id FROM orders)：若orders.user_id有 NULL，优化器无法判断结果集大小，常低估 10–100 倍 -
WHERE EXISTS (SELECT 1 FROM logs l WHERE l.user_id = u.id AND l.created_at > '2025-01-01')：若logs(created_at)无索引，预估行数可能按总表行数 × 时间范围占比硬算，偏差极大
统计信息无法覆盖嵌套产生的新分布
基表的统计信息（如 users.status 直方图）只描述原始列分布，不描述嵌套后中间结果的行数、空值率或关联倾斜度。例如 SELECT COUNT(*) FROM (SELECT DISTINCT user_id FROM orders WHERE amount > 1000) t，优化器根本不知道 t 实际只有 200 行还是 20 万行——它只能基于 orders.amount 单列统计反推，而金额高阈值往往对应极强的长尾分布。
- 嵌套中出现
GROUP BY、DISTINCT、UNION ALL等操作，会彻底改变行数分布形态，原统计信息完全失效 - 复合条件（如
WHERE a = ? AND b IN (SELECT ...)）触发跨表基数联合估算，CE 模型默认按独立事件乘法计算，忽略真实相关性 - 手动
UPDATE STATISTICS或ANALYZE对嵌套中间结果无效，必须拆解后单独分析各层输出分布
真正卡住人的，从来不是“怎么写嵌套”，而是没意识到：每一层嵌套都在把优化器往盲区里推——你看到的执行计划变慢，只是失真后的结果，不是原因。
