子查询超过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控制深度，否则树形数据异常时可能栈溢出
真正难处理的从来不是“写几层”，而是“每层有没有索引支撑”——没有索引的递归或子查询，三层和三十层，性能差距只是时间问题，不是本质区别。
