RIGHT JOIN适合补全右表所有维度值，其本质是确保右表每行必出、左表匹配则填充否则填NULL，典型用于统计空分组并补零，但需注意WHERE过滤左表字段会退化为INNER JOIN，且SQLite等环境不支持。
RIGHT JOIN适合补全右表所有维度值
当你要确保某个维度表（比如departments、categories、products）的每一行都出现在结果里，哪怕它在事实表中完全没数据，RIGHT JOIN就是最直接的表达方式。它的本质不是“把右表拼过去”，而是“右表每行必须出，左表能配就配，配不上就填NULL”。
- 典型场景：统计每个产品类别销量，但要求即使某类别还没上架商品（事实表为空），也要显示该类别且销量为 0
- 关键前提：右表字段具备业务主键或唯一标识（如
category.id），否则GROUP BY会塌缩 - 常见误用：把
RIGHT JOIN当成“左右换位的LEFT JOIN”，忽略驱动表语义——右表才是结果的锚点
RIGHT JOIN + GROUP BY 统计空分组时 COUNT() 要选对字段
COUNT(*)和COUNT(左表字段)在RIGHT JOIN后行为完全不同，直接影响空分组是否显示为 0。
-
COUNT(f.id)只统计左表非NULL的行，空匹配时返回 0 —— 这是你想要的“补零”效果 -
COUNT(*)统计的是结果集总行数，哪怕左表全NULL，右表一行也会让该分组计数为 1 - 如果用了
SUM(f.amount)或AVG(f.amount)，它们对空匹配返回NULL，必须搭配COALESCE(SUM(f.amount), 0)
WHERE 条件写错会让 RIGHT JOIN 变成 INNER JOIN
这是最隐蔽也最常踩的坑：在WHERE里直接过滤左表字段，比如WHERE orders.status = 'shipped'，会把右表中所有没匹配订单的记录一并剔除。
- 正确做法一：条件移到
ON子句，如ON customers.id = orders.customer_id AND orders.status = 'shipped' - 正确做法二：显式允许
NULL，如WHERE orders.status IS NULL OR orders.status = 'shipped' - 错误写法后果：右表“孤儿行”被过滤，实际效果等同于
INNER JOIN，但你可能根本没意识到
RIGHT JOIN 在 SQLite 和部分 ORM 中不被支持
别假设所有环境都能跑通RIGHT JOIN。它不是“语法糖”，而是有明确兼容性边界。
- SQLite 直接报错：
near "RIGHT": syntax error，必须改写为LEFT JOIN并调换表序 - Django ORM、SQLAlchemy 等主流 ORM 默认不生成
RIGHT JOIN，强行构造可能触发底层降级或报错 - MySQL 8.0+、PostgreSQL、SQL Server 支持，但执行计划里通常会被优化器重写为
LEFT JOIN，性能无差别，可读性却下降
真正需要RIGHT JOIN的时候很少——多数所谓“右表为主”的需求，其实只是维度表放右边了。把它翻过来写成LEFT JOIN，语义更直白，兼容性更好，维护成本更低。
