结论：用 inner join 最稳妥，但必须确认主键在两张表中都非空且值完全对齐；否则得先查 null 和重复值，不然结果行数会意外缩水或膨胀。
直接说结论：用 INNER JOIN 最稳妥，但必须确认主键在两张表中都非空且值完全对齐；否则得先查 NULL 和重复值，不然结果行数会意外缩水或膨胀。
为什么 INNER JOIN 常被误用成“自动匹配”
很多人以为只要写 ON t1.id = t2.id，数据库就会“聪明地”把相同 ID 的记录拉出来。实际上它只做严格等值匹配，不处理缺失、类型不一致或隐藏空格等问题。
-
id在表 A 是INT，在表 B 是VARCHAR—— 某些数据库（如 MySQL）会隐式转换，但 PostgreSQL 直接报错operator does not exist: integer = character varying - 表 B 的
id字段含前导空格（' 123'），而表 A 是干净的123—— 匹配失败，该行被丢弃 - 表 B 中某个
id出现 3 次（比如维度表没去重），会导致结果行数翻 3 倍（笛卡尔积效应）
怎么提前发现主键对不齐的问题
别急着写 JOIN，先跑两组诊断查询：
SELECT COUNT(*) FROM table_a WHERE id IS NULL; SELECT COUNT(*) FROM table_b WHERE id IS NULL;
再看值分布是否一致：
SELECT id, COUNT(*) FROM table_a GROUP BY id HAVING COUNT(*) > 1; SELECT id, COUNT(*) FROM table_b GROUP BY id HAVING COUNT(*) > 1;
- 如果任一表有
NULL，INNER JOIN会直接跳过这些行——这不是 bug，是 SQL 标准行为 - 如果某
id在表 B 里重复，说明它可能不是真正的主键，或是宽表建模时未聚合（比如明细级 vs 汇总级） - 用
SELECT COUNT(DISTINCT id)对比两张表，差值大就说明覆盖不全
LEFT JOIN 和 FULL OUTER JOIN 什么时候该用
当你要保留事实表全部记录（比如订单表），但维度信息可能缺失（比如客户信息还没补全），就用 LEFT JOIN table_b ON ...。此时表 B 中没匹配上的字段全为 NULL，你能一眼看出哪些订单缺客户数据。
-
FULL OUTER JOIN很少用于星型模型，但在 ETL 调试阶段有用：能同时看到“表 A 有但表 B 没有”和“表 B 有但表 A 没有”的 ID，快速定位同步断点 - 注意：MySQL 不支持
FULL OUTER JOIN，得用LEFT JOIN+RIGHT JOIN+UNION模拟 - 所有外连接都要警惕
WHERE条件写错位置——比如LEFT JOIN ... WHERE b.status = 'active'实际会把没匹配上的行也过滤掉，等效于INNER JOIN
JOIN 后字段名冲突和别名陷阱
两张表都有 name 字段？不加别名直接 SELECT * 会报错或返回不可预测的列顺序。必须显式指定：
SELECT a.id, a.name AS customer_name, b.name AS product_name FROM customers a JOIN products b ON a.product_id = b.id;
- 表别名（
a,b）建议始终使用，尤其在多表 JOIN 时避免column reference is ambiguous - 别名不要用关键字（比如
order,user），否则某些方言要加引号，增加维护成本 - 如果后续要加
WHERE过滤维度字段（如b.category = 'electronics'），记得确认该字段在 JOIN 后确实存在且非空——否则条件失效
真正麻烦的从来不是语法，而是两张表的主键看起来一样、实际语义或清洗程度不同。上线前至少跑一次 COUNT(*) 对比，再抽样几条 ID 手动查源数据，比调三天性能更省时间。
