INNER JOIN 在连接行数远小于左表时更快，因能利用索引和剪枝；LEFT JOIN 必须扫描左表全部数据，且右表条件误放 WHERE 会丢失未匹配行。
INNER JOIN 什么时候比 LEFT JOIN 快？
不是语法写得“看起来少”就快，关键看优化器能不能用上索引 + 是否能提前剪枝。INNER JOIN 在满足连接条件的行数远小于左表时，通常能利用
或哈希连接快速收敛；而 LEFT JOIN 即使右表没匹配项，也必须扫完左表全部数据——哪怕你只
，优化器也不敢跳过左表的未匹配行。
常见错误现象：
显示
且
高，但加了
后反而变慢——这是强行把 LEFT JOIN 当 INNER JOIN 用，却没让优化器重选执行计划
实操建议：先确认业务是否真需要保留左表无匹配的记录；如果只是想“过滤出有关系的数据”，直接用
，别加
补丁
参数差异：
对 INNER JOIN 的哈希连接影响大，但对 LEFT JOIN 的驱动表扫描几乎无用
LEFT JOIN 右表字段为 NULL 时，为什么 WHERE 条件放错位置会丢数据？
因为
是在连接完成之后过滤，而
是在连接过程中决定如何匹配。把本该写在
的右表条件挪到
，等于把 LEFT JOIN “降级”成 INNER JOIN——MySQL/PostgreSQL 都一样。
常见错误现象：写
，结果没订单的用户全没了
实操建议：右表的过滤条件，只要涉及“是否参与连接逻辑”，一律塞进
；只有真正要全局过滤最终结果的（比如
），才放
示例对比：
✅
❌
JOIN 太多导致执行计划崩掉，是加索引还是拆查询？
当
显示
列出现
或连接顺序明显反直觉（比如拿 100 万行的表当驱动表），说明成本模型已经失准——这时加索引往往无效，因为优化器根本没机会用上。
性能影响：5 张表以上 JOIN，MySQL 8.0 默认
，可能直接放弃穷举，退化为贪心算法，选错驱动表
实操建议：优先按主键或高频查询字段，把大表提前 JOIN；若仍不稳定，不如用应用层分两步查——比如先查
，再用
拉订单和地址，避免优化器在复杂谓词间反复权衡
容易踩的坑：
能强制顺序，但一旦底层数据分布变化（比如某表突然膨胀 10 倍），原来最优的顺序立刻变最差
RIGHT JOIN 几乎没人用，但它的语义真的不可替代吗？
语义上可以被
完全替代，只是调换左右表位置；但人在写复杂嵌套时，偶尔会因可读性临时用一下——比如从日志表出发，想强调“以事件为主，补上用户信息”，写成
看起来反直觉，其实只是把
放左边更顺眼。
兼容性影响：SQLite 不支持
；老版本 MySQL（5.6 之前）在子查询里用
可能触发 bug，报
实操建议：团队协作中统一禁用
；单人脚本里如果真用了，记得加注释说明“仅为保持主表在左”，否则半年后自己都看不懂
关键点：优化器内部一律转成
处理，执行计划不会因此变好或变差
事情说清了就结束。成本模型不是黑箱，但也不是手动能算出来的——它依赖统计信息准确度、配置阈值、甚至临时内存是否够用。别迷信
里的“key_len”，先看
和
是否合理，再动手调。
index nested-loop joinSELECT idEXPLAINtype=ALLrowsWHERE right_table.id IS NOT NULLINNER JOINIS NOT NULLjoin_buffer_sizeWHEREONONWHERELEFT JOIN orders ON users.id = orders.user_id WHERE orders.status = 'paid'ONusers.created_at > '2024-01-01'WHERELEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid'LEFT JOIN orders ON users.id = orders.user_id WHERE orders.status = 'paid'EXPLAINExtraUsing temporary; Using filesortjoin_optimizer_search_depth=6user_idsINSTRAIGHT_JOINLEFT JOINevents RIGHT JOIN usersusersRIGHT JOINRIGHT JOINUnknown column in 'on clause'RIGHT JOINLEFT JOINEXPLAINrowsfiltered