left join与right join本质对称可互换，建议统一用left join；on中误写where条件会使外连接退化为内连接；mysql不支持full outer join，需用left+right+union模拟；聚合函数默认忽略null，需用coalesce处理。

LEFT JOIN 和 RIGHT JOIN 本质是同一个东西

SQL 没有“真正的 RIGHT JOIN”，它只是 LEFT JOIN 的镜像写法，语义完全可互换。多数人用 LEFT JOIN 是因为阅读顺序更符合直觉：左表是主表，右表是补充数据。但如果你把两张表位置调换，RIGHT JOIN 就等价于 LEFT JOIN —— 不是语法糖，是数学对称性决定的。

实操建议：

• 统一用 LEFT JOIN，避免团队里有人写左、有人写右，导致逻辑翻转难排查
• 别在复杂多表连接中混用 LEFT 和 RIGHT，容易搞错驱动表（即哪张表保留所有行）
• RIGHT JOIN 在 PostgreSQL 和 SQL Server 中支持，在 SQLite 中不支持，MySQL 5.7+ 支持但解析器会悄悄转成 LEFT JOIN

ON 条件里写 WHERE 条件会把 OUTER 变成 INNER

这是最常踩的坑：LEFT JOIN ... ON a.id = b.a_id WHERE b.status = 'active' 看似想查“所有 a，附带 active 的 b”，实际效果是只返回那些有匹配且 status 为 active 的 a 行 —— 因为 WHERE 是在连接完成后过滤，把 b 为 NULL 的行全干掉了。

正确做法是把过滤条件挪进 ON：

这样，即使某个用户没有 active 订单，b.name 仍是 NULL，但该用户仍会被保留。

常见错误现象：

• 本该返回 100 行，结果只出来 23 行，且全是关联成功的记录
• 执行计划里显示 Hash Join 后紧跟 Filter，说明 WHERE 已介入连接逻辑
• 用 EXPLAIN 查看时，发现 rows 数远小于左表总行数，暗示 OUTER 失效

FULL OUTER JOIN 在 MySQL 中根本不存在

MySQL 直到 8.0.32 都不支持 FULL OUTER JOIN。你写上去会报错：ERROR 1064 (42000): You have an error in your SQL syntax。这不是版本问题，是设计取舍 —— 官方认为可用 LEFT JOIN + UNION + RIGHT JOIN 组合模拟。

替代写法（需去重，注意 NULL 匹配）：

但要注意：

• UNION ALL 比 UNION 快，前提是业务能容忍重复（比如两边都无匹配的 NULL 行不会出现两次）
• NOT IN 遇到 NULL 会整个失效，必须加 WHERE id IS NOT NULL
• PostgreSQL 和 SQL Server 原生支持 FULL OUTER JOIN，语法一致，无需改写

JOIN 后的 NULL 值处理不当会导致聚合出错

比如写 SELECT COUNT(b.id) FROM users a LEFT JOIN orders b ON a.id = b.user_id，你以为在统计“每个用户下的订单数”，其实是在统计“非 NULL 的 b.id 总数”——这没问题；但换成 SUM(b.amount)，就会忽略所有 b 为 NULL 的行，结果比预期小，而且不会报错、没提示。

关键点：

• COUNT(*) 统计所有行，COUNT(b.id) 只统计 b.id 非 NULL 行
• SUM、AVG、MAX 等聚合函数默认跳过 NULL，不是 bug，是标准行为
• 如果要体现“无订单用户金额为 0”，得显式用 COALESCE(b.amount, 0)
• 在 GROUP BY 场景下，NULL 分组可能被合并或丢失，尤其当 GROUP BY b.category 时，b 为 NULL 的行会单独成一组，容易被忽略

真正麻烦的是，这些 NULL 行在开发环境数据少时看不出问题，上线后数据量一大，统计偏差就暴露了 —— 而且很难回溯到底是 JOIN 写法、聚合逻辑，还是原始数据缺值导致的。