根本原因是聚合执行在JOIN之后，而一对多关联天然放大行数；例如users和orders用user_id关联，一个用户有3笔订单，JOIN结果产生3行，COUNT(*)返回3而非1，这是逻辑被中间膨胀结果污染所致。
为什么直接JOIN再聚合会翻倍
根本原因是聚合执行在JOIN之后，而一对多关联天然放大行数。比如users和orders用user_id关联，一个用户有3笔订单，JOIN结果就有3行——这时COUNT(*)算出来就是3，不是“1个用户”，而是“3条记录”。这不是函数失效，是逻辑被中间结果污染了。
常见错误现象：SELECT user_id, COUNT(*) FROM v_user_orders GROUP BY user_id返回值远大于SELECT COUNT(*) FROM users，说明视图输出已膨胀。别急着加DISTINCT，它只在最终结果层去重，而聚合早已完成。
子查询去重必须在聚合之前
关键动作要压到最内层：先确保参与聚合的维度本身不重复，再分组统计。例如统计每个用户的订单笔数（去重后），不能依赖视图输出，而应：
CREATE VIEW v_user_order_summary AS SELECT user_id, COUNT(*) AS order_count FROM ( SELECT DISTINCT user_id, order_id FROM orders ) AS deduped GROUP BY user_id;
这个写法里，DISTINCT作用于原始明细，避开JOIN干扰；外层GROUP BY只基于清洗后的user_id，语义清晰。
- 如果要去重的是“每个用户最新一条订单”，子查询里换成
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)，再过滤rn = 1 -
DISTINCT字段组合必须有对应联合索引，比如(user_id, order_id)，否则全表扫描+临时排序会拖慢整个视图 - 窗口函数中的
PARTITION BY和ORDER BY字段同样需要覆盖索引，否则ROW_NUMBER()触发磁盘排序
WHERE中用EXISTS替代IN避免NULL陷阱
查“下过单的用户”时，SELECT name FROM users WHERE id IN (SELECT user_id FROM orders)看似合理，但只要orders.user_id含NULL，整条IN判断就返回空——这是SQL标准行为，不是bug。
更稳写法是：
SELECT name FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
EXISTS不依赖值比较，只看是否存在匹配行，天然绕过NULL问题，且多数数据库对它有更好优化。
-
NOT IN比NOT EXISTS更危险：子查询结果里只要有一个NULL，整条语句就查不到任何数据 - 子查询返回多行却没被限制（比如漏
LIMIT 1），主查询会报错或结果错乱 - MySQL 5.7+、PostgreSQL、SQL Server 对
EXISTS的执行计划通常比IN更可预测
聚合结果二次计算必须拆两层
想算毛利率(revenue - cost) / revenue，不能在同一个SELECT里起别名再用——HAVING gross_margin > 0.2会报错，因为gross_margin在语法上不存在。
必须用子查询或CTE固化中间结果：
SELECT dept,
ROUND((revenue_sum - cost_sum) / NULLIF(revenue_sum, 0), 4) AS gross_margin
FROM (
SELECT dept, SUM(revenue) AS revenue_sum, SUM(cost) AS cost_sum
FROM sales
GROUP BY dept
) AS agg;这里NULLIF(revenue_sum, 0)防除零，ROUND(, 4)控浮点误差，都是线上环境容易忽略但一跑就崩的点。
- 子查询必须加别名，比如
AS agg，否则MySQL/PostgreSQL直接报错 - CTE更易读，但跨CTE引用字段需显式
SELECT出来，不能“凭空调用” - 如果某组根本没数据（如新部门），
SUM(salary)返回NULL，是否补COALESCE(, 0)取决于业务语义——是“无数据”还是“0元”
子查询位置决定逻辑干净度：写在WHERE里天然单值上下文，写在FROM里能控制聚合时机，但每一层都得确认索引是否跟得上，否则性能瓶颈不在SQL写法，而在底层数据组织。
