子查询慢主因是生成过大中间结果集，应优先用explain分析执行计划，改in为exists（外表小、内表大时）、转join或left join+group by，确保关联字段有索引，并避免盲目加distinct或limit。
子查询返回太多行导致慢查怎么办
子查询慢，往往不是语法错，而是它悄悄生成了远超需要的中间结果集。比如 WHERE id IN (SELECT user_id FROM logs WHERE created_at > '2024-01-01')，如果 logs 表没索引、数据量又大，这个子查询可能扫几百万行，再把几万 user_id 全拉出来去外层匹配——IO 和内存都扛不住。
- 确认子查询是否真有必要：先用
EXPLAIN看执行计划，重点看rows和Extra列，如果出现Using temporary; Using filesort或rows明显远大于最终结果数，说明中间集膨胀了 - 能转
JOIN就别硬套子查询：尤其是相关子查询（含外层字段），MySQL 8.0+ 对JOIN的优化远好于反复执行子查询 - 加上
LIMIT或DISTINCT前要三思：比如SELECT * FROM users WHERE id IN (SELECT DISTINCT user_id FROM events)，如果events.user_id本身有重复，DISTINCT会强制排序去重，反而更慢；不如先在events上建联合索引(user_id, created_at)
IN 子查询 vs EXISTS 子查询性能差异在哪
IN 和 EXISTS 看似等价，但执行逻辑完全不同：IN 先算出完整子结果集再做哈希查找；EXISTS 是对外表每行做一次“是否存在匹配”的半连接判断，找到一个就停。
- 外表小、内表大时，优先用
EXISTS：比如查“有没有订单的用户”，users表 1 万行，orders表 500 万行，EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id)通常比IN (SELECT user_id FROM orders)快得多 - 内表有高效索引时，
EXISTS优势更明显：确保orders.user_id有索引，否则EXISTS也会退化成全表扫描 -
IN不能处理NULL：如果子查询结果含NULL，整个IN表达式返回UNKNOWN，常被误判为“没匹配到”；EXISTS不受NULL影响
相关子查询被重复执行怎么避免
相关子查询（比如 SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) AS order_cnt FROM users）在 MySQL 5.7 及更早版本中，对 users 每一行都会重新执行一次子查询，10 万用户 = 执行 10 万次子查询。
- 改用
LEFT JOIN + GROUP BY：把聚合逻辑前置，SELECT u.name, COALESCE(o.cnt, 0) FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) o ON u.id = o.user_id - MySQL 8.0+ 可考虑物化 CTE：用
WITH order_counts AS (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) SELECT ... FROM users LEFT JOIN order_counts ...，优化器大概率会把 CTE 当作临时表物化，避免重复计算 - 别依赖“子查询自动优化”：即使文档说“优化器可能重写”，实际执行计划仍要看
EXPLAIN，尤其跨版本迁移时，行为可能突变
子查询性能问题最麻烦的点在于：它看起来简洁，却极容易掩盖数据规模和索引缺失的真实代价。一条 EXPLAIN 不看，就敢上线，基本等于靠运气跑。
