INNER JOIN仅返回两表匹配的行，LEFT JOIN返回左表全部行且右表无匹配时填NULL；二者核心区别在于结果集行数控制逻辑，而非性能或语法简洁性。
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，就等于默认剔除了未注册用户、测试账号、禁用账户……这些往往才是排查问题的关键线索。