MySQL多层嵌套查询性能断崖式下降的主因是相关子查询逐行执行导致O(n×m×k)级放大，且超3层后优化器放弃代价估算，易引发全表扫描、临时表膨胀及索引失效。
SELECT 语句里套 SELECT，本身不难；但真正踩坑的，是嵌套层级一深，性能断崖式下跌、逻辑错乱、甚至查不出数据。MySQL 不支持真正的“循环”，所谓“多层嵌套”，本质是子查询嵌套子查询，必须严格按执行顺序一层层展开。
WHERE 中多层嵌套：先确认返回值类型
WHERE 子句里的子查询，最终必须能和左侧表达式做合法比较（比如单值比单值、行比行、列比列）。一旦嵌套过深，很容易出现「子查询返回多行但被当单值用」的错误，报错信息通常是：Subquery returns more than 1 row。
- 如果外层条件用的是
=或>，内层子查询必须只返回一个标量值（例如(SELECT MAX(id) FROM logs WHERE status = 'done')） - 如果用的是
IN，内层可以返回一列多行（例如SELECT user_id FROM banned_users），但不能返回两列 - 嵌套三层时，建议把第二层结果先用
WHERE ... IN (SELECT ...)拆出来验证是否真的只有一行/一列，避免隐式类型转换失败
FROM 中嵌套派生表：别名和字段引用要显式
把子查询当临时表用（即FROM (SELECT ...) AS alias）是最可控的多层写法，但容易忽略两个细节：
- 每层子查询都必须带
AS别名，否则 MySQL 8.0+ 会报错：Every derived table must have its own alias - 内层子查询里的字段，如果和外层同名，必须在最外层用
alias.column显式引用，否则可能被解析成错误作用域的字段 - 示例中常见错误：
SELECT id FROM (SELECT id FROM users WHERE id IN (SELECT user_id FROM orders)) t WHERE id > 100—— 看似没问题，但如果内层orders表有id字段，而你没加表别名，MySQL 可能混淆字段来源
SELECT 列中嵌套：慎用 correlated 子查询
在SELECT 列里写子查询（比如计算每个用户的最新订单时间），本质是**相关子查询**：每行主查询都会触发一次子查询执行。层数越多，性能越危险。
- 两层嵌套（如
(SELECT MAX(created_at) FROM orders o WHERE o.user_id = u.id)）尚可接受；三层（比如再套一层查该订单的支付状态）基本会导致全表扫描放大 N×M×K 倍 - 替代方案优先考虑
JOIN + GROUP BY或窗口函数（ROW_NUMBER() OVER (PARTITION BY ...)），尤其在 MySQL 8.0+ - 如果必须用，确保所有关联字段都有索引，特别是子查询里
WHERE条件涉及的字段（如user_id、order_id）
多层嵌套不是不能写，而是每加一层，就要多验一次：返回值是否唯一、别名是否冲突、索引是否覆盖、执行计划是否走全表扫描。最隐蔽的问题往往出在第三层子查询悄悄返回了空集或 NULL，导致整行被过滤掉——而你根本没意识到它本该有数据。
