JOIN后避免重复数据应优先用DISTINCT或GROUP BY，但更稳妥的是先聚合再JOIN；UPDATE时MySQL支持JOIN语法，PostgreSQL需用FROM子句；Upsert须依赖数据库原生命令而非单纯JOIN；LEFT JOIN中右表过滤条件必须放在ON而非WHERE，否则NULL行被误滤。
JOIN 后怎么避免重复数据？
直接用
很容易把一对多关系炸成多行，比如一个用户有 3 条订单，
后用户信息就重复出现 3 次。这不是“数据错了”，而是 JOIN 本身的语义——它按匹配关系做笛卡尔积式拼接。
真要去重，优先想
或
，但得清楚去的是哪一层的重：是整行去重？还是只保证用户 ID 不重复？
看似简单，但只要 SELECT 里有聚合字段（如
）或不同订单时间，
就失效——它对整行生效，不是对某列
更稳的方式是先聚合再 JOIN：比如用子查询或 CTE 把订单表按
汇总成一行（
、
），再和用户表关联
UPDATE 时能用 JOIN 吗？MySQL 和 PostgreSQL 差在哪？
能，但语法不通用。MySQL 支持
直写，PostgreSQL 必须用
子句，SQL Server 则要加
扩展写法。
MySQL 示例：
PostgreSQL 示例：
注意：PostgreSQL 的
不是标准 SQL，且 WHERE 条件必须精确匹配更新目标行，漏写或写错会导致意外全表更新
所有数据库中，JOIN 更新前务必加
限制，最好先用
模拟一遍连接结果，确认行数和逻辑
唯一约束冲突时，JOIN 配合 INSERT 怎么安全 Upsert？
单纯靠 JOIN 做不了 Upsert；它只是连接手段，真正处理冲突得靠数据库原生命令，比如
（PostgreSQL）或
（MySQL）。
常见错误：先
判断是否存在，再决定
或
—— 这在并发下必然出错，中间可能已被其他事务插入
正确做法是让数据库自己判：用
，再叠加冲突子句
例如 PostgreSQL：
注意
是 PostgreSQL 关键字，MySQL 对应的是
，别混用
LEFT JOIN + WHERE 条件写错位置，为什么查不到 NULL 行？
这是最隐蔽也最常踩的坑：把本该放在
的过滤条件，错写进了
，导致
变成
效果。
比如：
—— 这会过滤掉所有没订单或订单非 paid 的用户，NULL 行全没了
正确写法是把过滤移到
：
原因：WHERE 在 JOIN 完成后执行，而 ON 是 JOIN 过程中决定如何匹配的；对右表的筛选，必须放 ON 才保留左表主干
检查方法：先把 WHERE 去掉，SELECT 出所有字段，看右表字段是否真有 NULL；再逐步加条件，观察 NULL 行是否消失
JOIN 不是万能胶，它本身不负责去重、不处理冲突、也不决定更新逻辑。真正的控制点永远在你怎么组合它——和聚合、和子查询、和数据库特有语法一起用。最容易被忽略的，是 ON 和 WHERE 的语义边界，一不留神，整个结果集就悄悄变形了。
JOINLEFT JOINDISTINCTGROUP BYDISTINCTCOUNT()DISTINCTuser_idMAX(order_time)COUNT(*)UPDATE ... JOINFROMUPDATE ... FROMUPDATE users u JOIN temp_updates t ON u.id = t.user_id SET u.status = t.new_statusUPDATE users SET status = t.new_status FROM temp_updates t WHERE users.id = t.user_idFROMWHERESELECTINSERT ... ON CONFLICTINSERT ... ON DUPLICATE KEY UPDATESELECTINSERTUPDATEINSERT INTO ... SELECT ... FROM other_table JOIN ...INSERT INTO users (id, name) SELECT id, name FROM staging_users ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.nameEXCLUDEDVALUES(column)ONWHERELEFT JOININNER JOINLEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'ONLEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'