LEFT JOIN保留左表全部行且右表无匹配时填NULL，结果行数恒等于左表行数；INNER JOIN仅返回两表交集行，结果行数≤任一表行数。
LEFT JOIN 和 INNER JOIN 的语义差异直接决定结果集行数
选哪个不是看“写起来顺不顺”，而是看你要的数据逻辑是否允许丢失左表记录。INNER JOIN 的结果行数 ≤ 左表或右表的任一表行数；LEFT JOIN 的结果行数 ≡ 左表行数——这是最硬的判断依据。
常见错误现象：LEFT JOIN 后加了 WHERE 条件过滤右表字段（比如 WHERE o.status = 'paid'），结果却漏掉了没订单的用户。这是因为 WHERE 会把右表为 NULL 的整行筛掉，实际等效于 INNER JOIN。
正确做法是把右表的过滤条件挪到 ON 子句里：
SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';
-
ON中的条件在连接时生效，不影响左表保留 -
WHERE中的条件在连接后生效，会剔除左表无匹配的行 - 如果既要保留所有用户，又要统计已支付订单，必须用
AND扩展ON
INNER JOIN 更快，但前提是关联字段有索引
很多人默认认为 INNER JOIN 性能一定比 LEFT JOIN 好，其实不然——关键在索引。没有索引时，两者都会触发全表扫描，LEFT JOIN 甚至可能更慢，因为它必须确保左表每行都参与连接计算。
使用场景中容易忽略的点：
- 关联字段类型要严格一致（比如
INT对CHAR会导致索引失效） -
JOIN顺序影响执行计划：小表放前面，MySQL 更容易用它驱动大表 -
EXPLAIN中看到type: ALL就说明没走索引，得立刻检查字段定义和索引
LEFT JOIN 不等于“安全兜底”，NULL 值会污染聚合和比较
用 LEFT JOIN 查所有用户及其订单数，写成 COUNT(o.id) 没问题，但换成 SUM(o.amount) 就得小心：o.amount 是 NULL 时，SUM 会跳过它，结果看似正确，实则掩盖了数据缺失事实。
更隐蔽的问题出现在 WHERE 或 HAVING 中的比较：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
o.amount > 100会自动排除NULL行（符合预期） o.amount 同样排除 <code>NULL行（不符合业务直觉）- 需要显式写成
o.amount 才完整
这类逻辑漏洞不会报错，但报表数字对不上时，90% 出在这里。
RIGHT JOIN 基本可以不用，LEFT JOIN 调换表序就能替代
MySQL 支持 RIGHT JOIN，但工程实践中几乎没人用。原因很简单：可读性差 + 容易混淆主次。
比如想查所有订单及对应用户信息（含用户不存在的脏数据），写成：
SELECT o.order_id, u.name FROM orders o RIGHT JOIN users u ON o.user_id = u.id;
不如直接写成：
SELECT o.order_id, u.name FROM users u LEFT JOIN orders o ON u.id = o.user_id;
后者一眼看出“以用户为主”，逻辑清晰。强行用 RIGHT JOIN 只会让后续维护的人多花三秒理解意图——而这三秒在复杂查询里可能变成半小时排查。
真正复杂的地方从来不是语法本身，而是你忘了 ON 和 WHERE 对 NULL 的不同处理方式，以及索引缺失时执行计划的悄然退化。
