子查询超过3层极易引发性能崩塌，因优化器常放弃精确代价估算，转而生成低效临时表与全表扫描组合，且每层均可能重复执行内层逻辑，导致O(n×m×k)级性能恶化。

MySQL 子查询超过 3 层就该警惕性能崩塌

MySQL 官方文档和生产实践都表明，子查询嵌套超过 3 层后，优化器极大概率放弃合理执行计划，转而生成低效的临时表+全表扫描组合。这不是“建议上限”，而是实际触发慢查询的常见临界点。

• 每多一层，MySQL 就要为内层结果建一次临时表，且该表 默认无索引，外层查询只能全扫
• 相关子查询（含 WHERE ... IN (SELECT ...) 或 EXISTS 套娃）在 3 层以上时，可能对主表每一行重复执行内层逻辑，O(n×m×k) 级别放大
• EXPLAIN 中若出现 select_type=DEPENDENT SUBQUERY 且嵌套 ≥3 次，基本可判定是性能雷区

MaxCompute 对子查询深度没硬限，但分区列 + 子查询 = 1000 行熔断

MaxCompute 不限制子查询嵌套层数，但它对「含分区列的子查询」做了强约束：子查询返回结果不能超过 1000 行。一旦超限，直接报错中断，不是慢，是失败。

• 典型场景：你在 WHERE pt IN (SELECT DISTINCT pt FROM logs WHERE ds='20260410') 里查分区，子查询一不小心扫出 1001 个分区值，整个 SQL 就挂
• 这不是性能问题，是平台级保护机制；绕过方式只有提前聚合、用 VALUES 列表或拆成两步写入中间表
• 注意：这个 1000 行限制只作用于「子查询中引用了分区字段」的情形，普通字段子查询不受此限

用 JOIN 替代多层子查询时，索引失效的隐藏坑

很多人以为把 SELECT * FROM A WHERE id IN (SELECT aid FROM B WHERE x > 10) 改成 JOIN 就万事大吉，但实际常因连接条件写法不当，让索引彻底失效。

• 错误写法：ON a.id = b.aid + 0 或 ON CAST(a.id AS CHAR) = b.aid_str —— 任意函数包裹/隐式转换都会使 aid 索引无法走
• 正确姿势：确保 JOIN 字段类型完全一致，且不参与任何表达式；b.aid 必须有索引，a.id 也最好有
• 特别注意 MySQL 8.0+ 的哈希连接（Hash Join）默认关闭，复杂 JOIN 仍可能退化为嵌套循环，EXPLAIN FORMAT=TREE 才能看清真实执行路径

递归查询（WITH RECURSIVE）比子查询更危险：没索引=秒变全表扫描

递归查询不是子查询，但常被误当作“高级子查询”来用。它的性能杀手不在层数，而在 parent_id 或 id 字段是否建了索引。

• 哪怕只递归 5 层，只要 parent_id 没索引，每次迭代都触发一次全表扫描，总成本 ≈ 5 × 表行数
• 必须同时建两个索引：INDEX (parent_id)（用于找子节点）和 INDEX (id, parent_id)（避免回表）
• PostgreSQL 和 SQL Server 支持 MAXRECURSION，MySQL 8.0+ 需手动加 LIMIT 控制深度，否则树形数据异常时可能栈溢出

真正难处理的从来不是“写几层”，而是“每层有没有索引支撑”——没有索引的递归或子查询，三层和三十层，性能差距只是时间问题，不是本质区别。