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