INNER JOIN 只要匹配的行，LEFT JOIN 要左表全部
这是最根本的区别：`INNER JOIN` 像严格筛选，两表必须有对应关系才出结果；`LEFT JOIN` 则“保左不保右”，左表每条记录都强制出现，右表没匹配上就填
NULL。
比如查订单和客户信息：
– 用
INNER JOIN orders ON customers.id = orders.customer_id→ 只显示「有订单的客户」；
– 改成
LEFT JOIN orders ON customers.id = orders.customer_id→ 显示「所有客户」，没下单的客户那几列订单字段全是
NULL。 别误以为
LEFT JOIN是“更全”的版本——它全的是左表，不是逻辑上“更完整”的数据集 如果 WHERE 条件里写了右表字段（如
WHERE orders.status = 'paid'），会悄悄把
LEFT JOIN变成事实上的内连接（因为
NULL不满足等值判断） 想保留左表又过滤右表，得把条件挪到
ON子句里，而不是
WHERE
LEFT JOIN 的 NULL 是信号，不是错误
LEFT JOIN结果里出现
NULL不代表 SQL 写错了，它是在告诉你：“这行左表数据，在右表里找不到搭档”。这个
NULL是设计行为，不是 bug。
常见误操作：
– 看到
NULL就急着加
WHERE xxx IS NOT NULL，结果绕回
INNER JOIN效果；
– 或者在应用层对
NULL做空指针处理，却忘了数据库里
NULL != NULL，不能用
=判断。 检查右表缺失时，用
WHERE right_table.id IS NULL（这是找“左表独有”数据的标准写法） 聚合时注意：
COUNT(*)会算
NULL行，
COUNT(right_table.id)会自动忽略
NULL如果业务上不允许
NULL，应在建表时设
NOT NULL+ 默认值，而不是靠 JOIN 类型兜底
性能差异常被高估，但执行计划真不一样
很多人直觉认为
LEFT JOIN比
INNER JOIN慢，其实不一定。MySQL 优化器对两者处理策略不同：
–
INNER JOIN可能先过滤再连接，甚至自动选择小表驱动大表；
–
LEFT JOIN必须先扫完左表，再逐行去右表找匹配，无法跳过左表任何一行。 左表数据量大且无索引时，
LEFT JOIN的 I/O 和内存压力明显更高
EXPLAIN里看
type字段：如果是
ALL（全表扫描）+ 左表行数巨大，就得警惕 右表关联字段没索引？
INNER JOIN可能只慢一点，
LEFT JOIN很可能直接卡住
RIGHT JOIN 几乎没存在必要
MySQL 支持
RIGHT JOIN，但实际项目里几乎没人用。它和把左右表调换位置 + 改用
LEFT JOIN完全等价，纯属语法冗余。
例如：
SELECT * FROM A RIGHT JOIN B ON A.id = B.a_id
和
SELECT * FROM B LEFT JOIN A ON B.a_id = A.id
结果一模一样，后者可读性还更好。 团队协作时统一用
LEFT JOIN，避免有人盯着
RIGHT JOIN发愣 某些 ORM 或 BI 工具生成 SQL 时可能冒出
RIGHT JOIN，建议手动转写 MySQL 8.0+ 对
RIGHT JOIN的优化支持不如
LEFT JOIN成熟，能避则避
真正容易被忽略的点是：JOIN 类型决定的是“哪些行该出现在结果里”，而不是“怎么查更快”或“怎么写更短”。选错类型，轻则漏数据，重则让统计口径彻底跑偏——比如把「所有用户订单数」写成
INNER JOIN，就等于默认剔除了未注册用户、测试账号、禁用账户……这些往往才是排查问题的关键线索。
