JOIN后SUM/COUNT翻倍是因JOIN先膨胀数据再聚合，须将聚合下推至JOIN前：右表按外键分组后再LEFT JOIN，并用COALESCE处理NULL；字段歧义需显式别名；存在性判断优先用EXISTS而非JOIN。
JOIN后SUM/COUNT结果翻倍怎么救
不是函数写错了，是执行顺序导致的必然现象：JOIN先膨胀数据，聚合再算——订单1条匹配3条明细，金额就被加了3遍。直接套SUM(DISTINCT amount)没用，它去重的是数值本身，不是行。
必须把聚合压到JOIN之前，切断“一行变多行”的链条：
- 右表（如
order_items）先按外键order_id分组：GROUP BY order_id，算出SUM(price)、COUNT(*)等 - 再用
LEFT JOIN连主表，确保没明细的订单也能保留（别漏COALESCE(..., 0)） - JOIN条件字段类型要一致，比如
orders.id是INT，order_items.order_id也得是INT，否则隐式转换会让索引失效甚至全表扫描
SELECT o.id, o.order_date, COALESCE(i.total_price, 0) AS total_price FROM orders o LEFT JOIN ( SELECT order_id, SUM(price) AS total_price FROM order_items GROUP BY order_id ) i ON o.id = i.order_id;
只取最新一条关联记录，为什么WHERE里写rn = 1就丢数据
ROW_NUMBER()确实能标出“最新”，但过滤位置错了：写在WHERE里会先JOIN再过滤，没日志的用户直接被踢掉（等效于INNER JOIN）；写在ON里才能保留空匹配。
正确姿势是把窗口函数放进子查询或CTE，然后在ON中加AND rn = 1：
- PostgreSQL/MySQL 8.0+ 支持
LATERAL或带rn的子查询，语义更直白 -
PARTITION BY字段必须和JOIN条件字段完全一致，比如PARTITION BY user_id对应ON u.id = o.user_id - 别用
RANK()除非业务允许并列，ROW_NUMBER()才能保证每组只留1行
WITH clean_logs AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY log_time DESC) AS rn FROM t_log ) SELECT u.name, l.ip_addr, l.log_time FROM users u LEFT JOIN clean_logs l ON u.id = l.user_id AND l.rn = 1;
SELECT * + JOIN = 字段歧义炸弹
两表都有id、created_at，SELECT *不是省事，是埋雷：PostgreSQL报错column reference "id" is ambiguous，MySQL旧版随机留一个值，应用层根本不知道拿到的是哪张表的id。
所有字段必须显式带表别名，冲突列一律用AS重命名：
-
ON子句里每个字段都加前缀，比如ON u.id = o.user_id，绝不能写ON id = user_id - 别用
NATURAL JOIN，它靠同名列自动匹配，加个字段就崩 - 子查询里也要提前重命名，否则外层无法区分
user_id和order_id
SELECT u.id AS user_id, u.name AS user_name, o.id AS order_id, o.amount, o.created_at AS order_created_at FROM users u JOIN orders o ON u.id = o.user_id;
只判断“有没有”，为什么还硬JOIN
如果目标只是查“哪些用户有订单”，而非“订单详情”，LEFT JOIN ... WHERE o.id IS NULL看着顺，实则危险：右表重复、NULL、索引失效都会让结果失真；而EXISTS天然规避这些，找到第一条就停，不拉数据、不膨胀、不踩坑。
改写成本极低，逻辑还更清晰：
-
EXISTS返回布尔值，不暴露右表字段——这反而是提醒你：如果需要字段，说明目标本就不是存在性判断 -
NOT EXISTS替代LEFT JOIN ... IS NULL，避免因右表一对多导致主表行被复制后误判 - 确保
EXISTS子查询里的关联字段有索引（如t_log(user_id)），否则性能可能比JOIN还差
-- 查所有有订单的用户 SELECT u.id, u.name FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id ); <p>-- 查所有没头像的用户 SELECT u.id FROM users u WHERE NOT EXISTS ( SELECT 1 FROM avatars a WHERE a.user_id = u.id );
实际执行时最容易被忽略的点：JOIN的结果结构由连接逻辑决定，和SELECT列表无关。哪怕你只写SELECT u.id，数据库仍会先完成完整JOIN再投影——所以问题不在“选什么”，而在“怎么连”。
