INNER JOIN适用于必须匹配的场景，仅返回两表中连接字段完全匹配的记录，如查询有订单的用户信息，不包含无订单用户或无效订单。
INNER JOIN 适合“必须匹配”的场景
当你明确只要两个表都存在的关联数据时，INNER JOIN 是最安全的选择。比如查“有订单的用户信息”，结果里不会出现没下单的用户，也不会出现 customer_id 不存在的脏订单。
常见错误是误用 LEFT JOIN 后又在 WHERE 里过滤右表字段（如 WHERE o.amount > 100），这会把本该保留的 NULL 行也干掉，实际效果等同于 INNER JOIN，但语义混乱、可读性差。
- ON 条件里避免函数或类型转换，比如
ON u.id = CAST(o.user_id AS CHAR)，索引大概率失效 - 多个
INNER JOIN连接时，表顺序不影响结果，但影响优化器选执行计划——小表放前面更稳妥 - 如果业务要求“严格一致”，比如权限校验、状态同步，优先从
INNER JOIN开始验证逻辑
LEFT JOIN 要盯紧“主表是谁”
LEFT JOIN 的结果行数由左表决定，右表只是“补充信息”。典型用法是查“所有用户及其订单汇总”，哪怕某些用户没下单，也要出现在结果里。
容易踩的坑是把主表放错位置。例如想查“所有订单及对应客户姓名”，却写成 customers LEFT JOIN orders，结果会把没下单的客户全列出来，而漏掉 customer_id 无效的订单（比如 orders.customer_id = 5 但 customers.id 没有 5）。
- 主表必须是你想“保底返回”的那张表，别被别名或业务术语带偏
-
ON子句里加右表过滤条件（如ON c.id = o.customer_id AND o.status = 'paid'）是合法且常用的做法，它只影响匹配行为，不筛掉左表行 - MySQL 不支持
FULL JOIN，但可以用LEFT JOIN+RIGHT JOIN+UNION模拟，注意去重和 NULL 处理
RIGHT JOIN 很少需要，多数情况可改写为 LEFT JOIN
语法上 RIGHT JOIN 和 LEFT JOIN 是镜像关系，但可读性差。比如 orders RIGHT JOIN customers 本质上等价于 customers LEFT JOIN orders，后者更符合“主表在左”的直觉。
真实项目中几乎没见过非用 RIGHT JOIN 不可的场景。强行使用反而增加协作成本，尤其对新成员来说，得倒着读逻辑。
- 遇到别人写的
RIGHT JOIN，第一反应是重写为等价的LEFT JOIN形式 - 如果连接链很长（比如 A RIGHT JOIN B RIGHT JOIN C），基本可以判定设计有问题——主表应该统一放在最左侧
- 某些旧系统迁移或 ORM 自动生成 SQL 时可能残留
RIGHT JOIN，不必强求立刻改，但新增代码禁止使用
ON 和 WHERE 的位置决定 NULL 是否被过滤
这是最隐蔽也最常出错的地方。ON 控制“怎么连”，WHERE 控制“连完怎么筛”。对 LEFT JOIN 来说，把右表字段条件写在 WHERE 里，等于间接把左表没匹配的行也剔除了。
比如想查“所有用户 + 其金额大于 100 的订单”，正确写法是把金额条件放进 ON：LEFT JOIN orders o ON c.id = o.customer_id AND o.amount > 100；错误写法是 LEFT JOIN orders o ON c.id = o.customer_id WHERE o.amount > 100，后者会让没订单的用户直接消失。
- 只要右表字段参与筛选，先问一句：这个筛选是“限制匹配范围”，还是“过滤最终结果”？前者放
ON，后者放WHERE -
INNER JOIN下两者效果一样，但习惯统一放ON更清晰，便于后续改成外连接时不出错 - 涉及多个外连接时，
WHERE条件可能跨表生效，务必用小数据集验证 NULL 行是否意外丢失
业务需求一旦涉及“保底返回”或“允许缺失”，JOIN 类型就不再是语法选择，而是数据语义的精确表达。最容易被忽略的是 ON 和 WHERE 的分工，它不报错，但悄悄改变结果集的基数。
