n+1查询问题是orm中因延迟加载导致先查主表（1次），再对每条主记录单独查关联表（n次），总计n+1次数据库查询。其本质是未使用预加载、join或批量查询优化，使查询次数随数据量线性增长，显著拖慢性能。
相关子查询为什么会触发 N+1 查询
当你写 SELECT u.name, (SELECT p.title FROM posts p WHERE p.user_id = u.id LIMIT 1) FROM users u，数据库无法一次性把所有 u.id 打包查 posts，而是对 users 的每一行都单独执行一次子查询。如果 users 有 5 万行，posts 又没索引，就等于做了 5 万次全表扫描。
EXPLAIN 中看到 DEPENDENT SUBQUERY 或 SubPlan 且 loops=50000，就是这个信号。它不是“慢一点”，是计算量直接从 O(N) 变成 O(N×M)。
- 即使子查询只返回 1 行，只要没被物化，就重复跑
- 优化器很难对相关子查询做连接重排或哈希优化
- MySQL 5.7 及更早版本默认不启用半连接优化，这类写法几乎必慢
JOIN 如何避免重复计算
JOIN 把关联逻辑交给执行引擎统一调度：先扫驱动表（比如 users），再用每行的 id 去被驱动表（posts）中查匹配项。只要 posts.user_id 有索引，每次查找就是 O(log M)，总代价约 O(N × log M)。
更重要的是，执行器能选择更优算法：
-
Hash Join：把小表建哈希表，大表单次扫描匹配，O(N + M) -
Merge Join：两表已排序时，归并即可，O(N + M) - 即使退化为
Nested Loop，索引也能把内层循环压到毫秒级
而相关子查询连进入这些算法的机会都没有——它根本不在同一个执行路径里。
为什么加了索引，JOIN 还可能比子查询慢
不是 JOIN 天然快，是“带索引的 JOIN”快。反过来，如果 posts.user_id 没索引，JOIN 实际走的是嵌套循环全表扫描，性能可能比物化后的标量子查询还差。
常见误判点：
- LEFT JOIN 却把右表过滤条件写在
WHERE里 → 实际转成 INNER JOIN，还丢了索引下推机会 - JOIN 多张大表且没指定驱动顺序 → 优化器选错驱动表，小表变内层，放大扫描量
- 用
STRAIGHT_JOIN强制顺序，但没验证统计信息是否准确 → 计划反而劣化
EXPLAIN 中若看到 type=ALL 出现在被驱动表，或 rows 高得离谱，别急着换写法，先加索引。
哪些子查询改 JOIN 是安全且提效的
满足这三条，基本可以放心改：
- 子查询是单表、单列、等值关联（如
WHERE p.user_id = u.id），不含IN、EXISTS、聚合函数 - 外层不依赖子查询的多行结果（比如没用
COUNT(*)或GROUP BY） -
posts.user_id字段已有索引，且不是低选择性字段（如 status=1 占 90% 行）
改写后记得加 EXPLAIN ANALYZE 对比实际 actual time 和 loops —— 看计划不如看真实耗时。很多人漏掉这点，只盯着“用了 Hash Join”就以为稳了，结果发现内存不足导致落盘，反而更慢。
