用JOIN替代子查询不一定更快，需看执行计划；相关子查询在SELECT列表中反复执行时才适合改JOIN，且须注意LEFT/INNER语义差异、索引优化及数据一致性。
用 JOIN 替代子查询，真能快？先看执行计划
不是所有子查询都该被换成 JOIN，盲目替换反而更慢。MySQL 5.7+、PostgreSQL 12+ 对相关子查询已有较好优化，但若子查询在 SELECT 列表里反复执行（比如每行都跑一次 (SELECT name FROM users WHERE id = orders.user_id)），就属于典型低效场景。
实操建议：
- 用
EXPLAIN或EXPLAIN ANALYZE看原语句是否出现DEPENDENT SUBQUERY—— 出现就大概率要改 - 子查询返回多行（如
IN (SELECT ...)）时，JOIN不一定更优；优先考虑EXISTS或物化临时表 - 如果子查询只查单值且字段有索引（如
user_id上建了索引），JOIN通常更稳，因优化器能更好估算行数
LEFT JOIN vs INNER JOIN：字段缺失时结果差得离谱
把 SELECT t1.id, (SELECT name FROM users u WHERE u.id = t1.user_id) 换成 LEFT JOIN users u ON u.id = t1.user_id，看着一样，但语义完全不同：前者 NULL 安全（没匹配到就返回 NULL），后者必须显式写 LEFT JOIN 才保 NULL；写成 INNER JOIN 就直接丢数据。
常见错误现象：
- 合并后总行数变少 → 很可能是误用了
INNER JOIN - 某些字段突然全为 NULL →
JOIN条件写错，或关联字段存在隐式类型转换（比如user_id是字符串但被当数字比较） - 结果重复翻倍 → 忘了
users表里一个id对应多条记录（比如历史重名用户未去重）
多个表合并时，ON 条件顺序和索引怎么配
JOIN 顺序本身不影响结果，但影响性能。优化器一般会重排，可强制用 STRAIGHT_JOIN（MySQL）验证，但更关键的是每个 ON 字段是否有对应索引。
使用场景举例：合并订单表 orders、用户表 users、地址表 addresses
-
orders.user_id → users.id：确保users.id是主键或有索引，orders.user_id也必须有索引 -
users.id → addresses.user_id：同理，addresses.user_id必须有索引；如果常用addresses.type = 'billing'过滤，考虑联合索引(user_id, type) - 避免在
ON里写函数，比如ON DATE(o.created_at) = DATE(u.registered_at)→ 索引失效，改用范围查询或预计算字段
字段名冲突？别硬记别名，用 USING 简化又安全
当两个表用相同字段名关联（如都是 id 或 user_id），用 USING (user_id) 比 ON a.user_id = b.user_id 更简洁，而且 SELECT 时不用加表前缀，也不会出现 column 'user_id' in field list is ambiguous 错误。
但要注意：
-
USING要求两边字段名、类型、字符集完全一致；MySQL 中VARCHAR(50) utf8mb4和VARCHAR(50) utf8会报错 - 一旦用了
USING，SELECT 中写user_id自动取合并后的唯一值；想分别取两边原始值，只能退回用ON+ 显式别名 - 三个表以上连查时，
USING只能用于两两之间，不能跨表复用，别指望它自动“传递”关联
最常被忽略的其实是数据一致性：JOIN 合并时，如果关联表有未提交事务或 MVCC 版本差异，结果可能和子查询不一致——这不是写法问题，是隔离级别决定的。线上调优前，先确认业务能否接受这种偏差。
