LEFT JOIN 中应将过滤条件放在 ON 而非 WHERE，否则会意外过滤左表空匹配行；维度表一对多需先聚合再 JOIN；JOIN 性能问题多因缺失索引或笛卡尔积；显式 ON 比 USING/NATURAL 更安全可靠。
JOIN 时 ON 和 WHERE 混用导致结果意外过滤
很多人写 LEFT JOIN 本意是保留左表全部记录，但一加 WHERE 条件就漏数据——问题常出在把本该写在 ON 的关联条件挪到了 WHERE。比如想查所有用户及其订单数，但又只想要「订单状态为 paid」的统计，如果写成：
SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' -- 错！这会让没订单的用户也被过滤掉 正确做法是把过滤条件放进 ON：
SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' 原因很简单：ON 控制“怎么连”，WHERE 控制“连完再筛”。LEFT JOIN 后加 WHERE 字段非空条件，等价于转成了 INNER JOIN。
多维表关联时 NULL 值引发计数 / 聚合偏差
补全地区、分类、标签等维度表后，常发现 COUNT() 或 SUM() 结果比预期大很多，甚至翻倍。典型原因是维度表存在一对多关系（比如一个商品有多个标签），而 JOIN 未去重或未提前聚合。
- 用
LEFT JOIN直接连标签表 → 每个商品行会复制 N 次，COUNT(*)就变成标签总数，不是商品数 - 正确思路：先对维度表聚合（如用
STRING_AGG(tag_name, ',')或子查询统计数量），再 JOIN - MySQL 8.0+ / PostgreSQL 支持
LATERAL，可更安全地做“每行触发一次子查询”
示例（PostgreSQL）：
SELECT u.name, t.tag_list FROM users u LEFT JOIN LATERAL (SELECT STRING_AGG(t.name, ',') AS tag_list FROM user_tags ut JOIN tags t ON ut.tag_id = t.id WHERE ut.user_id = u.id ) t ON trueJOIN 性能卡在没走索引或笛卡尔积
小表 JOIN 没问题，一上生产就慢，90% 是因为没索引或 ON 条件写错。常见坑：
-
ON a.id = b.user_id中，b.user_id没建索引 → 全表扫描，JOIN 成 O(n×m) - 用函数包装字段做关联，比如
ON LOWER(a.email) = LOWER(b.email)→ 索引失效（除非建函数索引） - 忘记加 JOIN 条件，或条件里混入恒真表达式（如
1=1），直接触发笛卡尔积 - MySQL 旧版本对
LEFT JOIN后的WHERE子句优化差，建议升级到 8.0+ 或改写为子查询
验证方法：执行 EXPLAIN，重点看 type 是否为 ref/eq_ref，rows 是否明显偏大。
不同数据库对 USING 和 NATURAL JOIN 的兼容性差异
想省事写 USING (id) 或 NATURAL JOIN？小心跨库迁移时翻车。
-
USING在 PostgreSQL / MySQL / SQLite 都支持，但 SQL Server 不支持 → 写死ON a.id = b.id更稳妥 -
NATURAL JOIN会自动匹配所有同名列，语义模糊且不可控，MySQL 8.0 已标记为废弃，PostgreSQL 虽支持但极易因新增同名字段崩逻辑 - Oracle 对
USING有特殊限制（比如不能和ON混用），报错信息是ORA-25155
结论：别图省事。显式写 ON 条件，哪怕多敲几个字，也比上线后查不出数据强。
关联分析真正难的不是语法，而是想清楚“这一行数据到底代表什么业务含义”。JOIN 后一行变多、变少、变 NULL，背后都是业务关系没理清。补维度前，先问一句：这个维度和主表，是不是真的是一对一或一对多？有没有中间状态没覆盖？
