RIGHT JOIN 语法写对了，但结果为空？检查左表是否真有匹配行
RIGHT JOIN 的核心是“以右表为基准，左表缺失则补 NULL”。很多人写完发现结果和预期相反，不是语法错，而是逻辑误判：以为 RIGHT JOIN 能自动“补全”右表所有数据——它确实会，但前提是右表数据本身得存在、且没被 WHERE 或 ON 条件意外过滤掉。
常见错误现象：RIGHT JOIN 后结果比右表记录还少，甚至为 0 行；WHERE 条件写在右表字段上却没加 IS NULL 判断，导致 NULL 行被直接剔除。
- ON 条件只控制“怎么连”，不决定“留不留”；真正影响最终行数的是 WHERE（它在连接后过滤）
- 想保留右表全部记录 + 左表匹配或 NULL，就别在 WHERE 中写
WHERE t1.id IS NOT NULL这类条件 - 右表别名要明确，避免和 LEFT JOIN 混用时搞反方向，比如
FROM orders o RIGHT JOIN users u ON o.user_id = u.id—— 这里u是右表，o是左表
RIGHT JOIN 和 LEFT JOIN 只是写法互换，别硬套“右表更主”的心理暗示
MySQL 不区分“主从表”，RIGHT JOIN 完全等价于把两个表顺序调换后的 LEFT JOIN。强行用 RIGHT JOIN 并不会提升性能，也不会改变执行计划，反而容易让团队成员读错逻辑。
使用场景：极少数情况，比如你正在维护一段遗留 SQL，原作者用了 RIGHT JOIN，且改写会牵扯大量测试；或者你在写子查询嵌套时，为保持缩进/可读性临时调换顺序。
-
SELECT * FROM a RIGHT JOIN b ON a.id = b.a_id≡SELECT * FROM b LEFT JOIN a ON a.id = b.a_id - EXPLAIN 显示的驱动表（type=ALL / ref）取决于索引和统计信息，跟 JOIN 类型写法无关
- 如果右表很大、左表很小，又没合适索引，
RIGHT JOIN一样会慢——优化重点永远是 ON 字段是否有索引，而不是 JOIN 方向
右表关联补全时，NULL 值字段参与计算易出错
用 RIGHT JOIN 做“补全”，常是为了让右表每条记录都出来，左表字段填 NULL。但一旦对这些字段做 SUM()、COUNT()、+ 运算，NULL 就开始捣乱。
常见错误现象：SUM(t1.amount) 返回 NULL 而不是 0；COUNT(t1.id) 忽略 NULL 行，导致计数偏小；t1.status + '_done' 整个字段变 NULL。
- 数值聚合前先用
COALESCE(t1.amount, 0)转默认值 - 想统计“有没有匹配”，别用
COUNT(t1.id)，改用COUNT(*)或SUM(CASE WHEN t1.id IS NOT NULL THEN 1 ELSE 0 END) - 字符串拼接必须包一层
CONCAT(COALESCE(t1.status, ''), '_done')，否则整列变 NULL
MySQL 8.0+ 中 RIGHT JOIN 没被废弃，但 ANSI 兼容性差，跨数据库迁移要小心
MySQL 支持 RIGHT JOIN，但 PostgreSQL、SQL Server 对它的解析更严格，有些旧版本甚至不支持。如果你写的 SQL 未来可能跑在别的引擎上，现在就该警惕。
兼容性影响：PostgreSQL 要求 RIGHT JOIN 的 ON 条件必须引用右表字段（否则报错），而 MySQL 更宽松；SQLite 根本不支持 RIGHT JOIN，只能手写子查询模拟。
- 跨库项目统一用
LEFT JOIN+ 表顺序调换来替代RIGHT JOIN，可读性和兼容性都更好 - 建模工具或 ORM（如 Django ORM、Sequelize）通常只暴露 LEFT JOIN 接口，硬写 RIGHT JOIN 可能触发未定义行为
- MySQL 8.0 的哈希连接优化对 LEFT/RIGHT 一视同仁，但开启
hash_join=on后，某些 RIGHT JOIN 场景下优化器仍可能选错驱动表
事情说清了就结束。RIGHT JOIN 真正难的不是语法，是意识到它不解决数据补全的业务问题——补全靠的是逻辑设计、默认值约定、以及对 NULL 的显式处理。
