相关子查询性能差，因其为外层每行重复执行，导致执行次数线性放大；难以利用索引优化；替代方案如JOIN、窗口函数通常更高效；小数据量时可接受，但需评估必要性与执行计划。
相关子查询性能差，核心在于它会为外部查询的每一行重复执行一次子查询，导致实际执行次数呈倍数增长，数据量稍大就容易拖慢整体速度。
执行次数随外层数据量线性放大
相关子查询的 WHERE 或 SELECT 中引用了外部查询的列（比如 t1.id = t2.t1_id），数据库无法一次性预计算子查询结果，只能在外层每取出一行时，动态代入参数再执行一遍子查询。若外层返回 10 万行，子查询就可能被执行 10 万次。
- 即使子查询本身很快（如走索引查单行），10 万次叠加的 I/O 和 CPU 开销也不容忽视
- 若子查询涉及多表连接或聚合，开销还会指数级上升
难以利用索引优化子查询内部
数据库优化器对相关子查询的推导能力有限。即便子查询条件列上有索引，优化器有时仍无法准确判断是否能复用、是否需要重写访问路径，最终可能选择全表扫描或低效连接方式。
- 例如：
SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.cust_id AND c.status = 'active')，若customers(id)有索引但status没有，且优化器未生成合适的索引合并，就可能扫全表 - 部分数据库（如 MySQL 5.6 以前）甚至不支持对相关子查询做半连接（semi-join）优化
替代方案通常更高效
多数相关子查询可改写为 JOIN、窗口函数或非相关子查询，让数据库一次性处理数据，减少重复计算。
- 用 LEFT JOIN + IS NOT NULL 替代 EXISTS
- 用 INNER JOIN 替代 IN（子查询返回非空）
- 用 ROW_NUMBER() OVER (...) = 1 替代按分组取首行的相关子查询
- 把子查询提前物化为临时表或 CTE（尤其当子查询逻辑复杂但结果集不大时）
不是所有情况都该避免，但需明确代价
小数据量、逻辑简单、外层行数极少（如只查某用户最新订单）时，相关子查询写法清晰、易维护，性能影响微乎其微。关键是在写之前心里有数：它是不是真必要？有没有更优等价写法？执行计划里是否真的走了预期索引？
不复杂但容易忽略。
