多数情况下应优先使用 join 而非子查询，因其执行效率更高、优化器支持更成熟；单值查询可用子查询，多列/多行场景首选 join；存在性判断用 exists 更安全高效；not in 遇 null 易出错，应改用 left join + is null；字段歧义须用表别名显式限定。
什么时候该用 JOIN 而不是子查询
多数情况下，JOIN 比等价的子查询更快，尤其当关联字段有索引、数据量大时。MySQL 优化器对 JOIN 的执行计划更成熟，而子查询（尤其是相关子查询）可能被反复执行多次。
但注意：如果子查询只查单个值（如 SELECT ... WHERE id = (SELECT user_id FROM logs LIMIT 1)），用子查询更直观且无性能损失；若需多列或多行结果再参与过滤或展示，优先考虑 JOIN。
- 用
INNER JOIN替代WHERE ... IN (SELECT ...)（后者在 MySQL 5.6+ 有优化，但旧版本易退化） - 避免在
WHERE中写(SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) > 0—— 改用LEFT JOIN orders ON ... GROUP BY u.id HAVING COUNT(*) > 0或EXISTS -
EXISTS通常比IN更适合判断存在性，因为它可短路（找到第一条就停），且能正确处理NULL
LEFT JOIN + IS NULL 替代 NOT IN 的必要性
NOT IN 遇到子查询结果含 NULL 时会整个返回空集，这是 SQL 标准行为，但极易被忽略导致逻辑错误。例如：
SELECT name FROM users WHERE id NOT IN (SELECT user_id FROM banned_users);
只要 banned_users.user_id 里有一个 NULL，整条语句查不到任何用户。
安全写法是用 LEFT JOIN 找未匹配项：
SELECT u.name FROM users u LEFT JOIN banned_users b ON u.id = b.user_id WHERE b.user_id IS NULL;
这个写法不依赖子查询是否含 NULL，语义清晰，且 MySQL 能高效利用索引。
嵌套查询中 EXISTS 和 IN 的实际表现差异
二者语义不同：IN 是值匹配，EXISTS 是存在性检查。性能上，EXISTS 在外表小、内表大时更有优势，因为它是对外表每行执行一次“是否存在”的探查，且可提前终止；IN 会先把子查询结果物化（除非优化器重写），再做哈希查找。
- 子查询返回大量行？倾向用
EXISTS - 子查询结果固定且少（如
IN (1, 2, 3)），IN更自然 - 子查询含聚合或复杂条件？
EXISTS更易写对，也更容易加索引（比如EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')可走(user_id, status)联合索引）
联合查询中别名和字段歧义的硬伤怎么避
多个表有同名字段（如 id、created_at）时，不显式限定会导致报错或取错值。MySQL 允许 SELECT * FROM a JOIN b，但一旦两表都有 id，SELECT id 就会报 Column 'id' in field list is ambiguous。
解决方式只有两个：显式用表别名前缀，或用 AS 重命名。
SELECT u.id AS user_id, u.name, o.order_no FROM users u INNER JOIN orders o ON u.id = o.user_id;
特别注意：在 ORDER BY、GROUP BY、HAVING 中也必须用别名或全限定名，不能依赖 SELECT 列序号（如 ORDER BY 1）—— 这种写法脆弱，一改 SELECT 顺序就崩。
嵌套查询里更要小心：外层无法直接引用内层 SELECT 的计算字段，除非用别名并在外层 FROM 子句中作为派生表暴露出来。
