inner join 不能用于需保留主表所有记录的场景，如统计未下单用户；错误地在left join的where中过滤右表字段会使其退化为inner join；right join基本可被left join替代；full outer join在mysql中不支持，业务“并集”宜用union。

INNER JOIN 什么时候不能用

当业务需要保留“主表中所有记录”，哪怕关联表没匹配项，INNER JOIN 就会悄悄丢数据——它只返回两边都存在的行。比如查「所有用户及其最近一笔订单」，若用 INNER JOIN，那些注册后还没下单的用户就彻底消失了。

常见错误现象：SELECT COUNT(*) 结果比预期少；报表里客户数对不上 CRM 系统；导出名单漏人但没报错。

• 适用场景：明确只要“有交集”的数据，比如「已支付订单 + 对应商品信息」
• 不适用场景：统计类查询、主表兜底需求、审计/合规要求保留原始行数
• 性能影响：通常最快，因优化器可提前过滤；但若误用导致业务逻辑错误，修复成本远高于性能收益

LEFT JOIN 后 WHERE 条件写错位置会变 INNER JOIN

LEFT JOIN 的本意是保左表全量，但一旦在 WHERE 子句里对右表字段加非空限制（如 WHERE o.status = 'paid'），数据库会先 JOIN 再过滤——此时右表为 NULL 的行被干掉了，效果等同于 INNER JOIN。

正确做法是把右表的过滤条件挪到 ON 子句里：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'。这样 NULL 行仍保留，只是 o.* 字段全为 NULL。

• 容易踩的坑：用 IDE 自动生成 SQL 或复制粘贴时，习惯性把所有条件塞进 WHERE
• 验证方法：查左表某条确认无匹配记录的行，看结果里对应右表字段是否为 NULL
• MySQL 8.0+ 和 PostgreSQL 对此行为一致；SQLite 部分旧版本有差异，需实测

RIGHT JOIN 基本没必要存在

除了极少数 legacy 代码或迁移到特定 ORM 的临时适配，RIGHT JOIN 完全可用 LEFT JOIN 调换表序替代。强行用 RIGHT JOIN 只会让后续维护者多花 3 秒反应“谁才是主表”。

真实使用场景几乎为零。连 MySQL 官方文档都建议：“Prefer LEFT JOIN for clarity.”

• 如果看到 RIGHT JOIN，优先重写为 LEFT JOIN 并交换左右表顺序
• 某些 BI 工具生成的 SQL 可能含 RIGHT JOIN，导出后建议人工检查并规范化
• JOIN 顺序不影响执行计划，但影响人脑解析效率——主表放左边是行业默认约定

业务上要“取并集”得用 UNION，不是 FULL OUTER JOIN

SQL 标准里的 FULL OUTER JOIN 理论上能合并左右表所有行，但 MySQL 根本不支持，PostgreSQL 支持但实际业务中极少需要——因为“并集”往往隐含去重、字段对齐、NULL 处理等额外逻辑，直接靠 FULL OUTER JOIN 很难干净实现。

更常见的是：把用户表和临时导入表的数据合并去重，或汇总不同来源的销售记录。这时用 UNION ALL（不去重）或 UNION（去重）配合子查询更可控。

• MySQL 用户别折腾 FULL OUTER JOIN 模拟方案，代码冗长且易出错
• UNION 要求列数、类型兼容，字段名以第一个子句为准——这点常被忽略导致应用层取值错位
• 性能上，UNION ALL 比 UNION 快得多，除非真需要去重，否则默认选前者

JOIN 类型不是语法选择题，是业务语义的直译。一个 WHERE 条件的位置偏差，就能让“查全部用户”变成“查已下单用户”——这种错误不会报错，只会静默污染结果。