COUNT或SUM翻倍是因为JOIN在聚合前已放大行数，如1用户3订单导致COUNT(*)=3；根本解法是在聚合前用子查询去重，确保每逻辑维度仅1行参与计算。
视图里直接聚合含重复数据，为什么COUNT或SUM会翻倍？
因为JOIN或关联操作在聚合前已经放大了行数。比如users和orders一对多关联后，一个用户有3条订单，COUNT(*)就会算出3；如果没意识到这点，直接在视图里写SELECT user_id, COUNT(*) FROM users u JOIN orders o ... GROUP BY user_id，结果就不是“用户数”，而是“订单数”。这不是函数错了，是逻辑被重复行污染了。
常见错误现象：SELECT user_id, COUNT(*) FROM v_user_orders GROUP BY user_id 返回的数值远超预期，查原始表却发现用户总数对不上。
- 先确认视图底层是否含JOIN：如果有，重复几乎必然存在
- 用
SELECT COUNT(*) FROM v_user_orders对比SELECT COUNT(*) FROM users，差距大说明视图输出已膨胀 - DISTINCT不能解决这个问题——它只在最终输出层去重，而聚合是在那之前执行的
用子查询在聚合前去重，比在视图定义里加DISTINCT更可靠
关键点在于：去重动作必须发生在聚合计算之前，且作用于参与聚合的维度本身。子查询能明确控制这一步时机，而视图级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;
这个写法把去重压到了最内层，确保COUNT(*)只统计逻辑上不重复的(user_id, order_id)组合。
- 子查询中
DISTINCT作用于原始明细，避免JOIN放大的干扰 - 外层
GROUP BY只基于清洗后的维度，语义清晰 - 如果要去重的是“每个用户最新一条订单”，子查询里可换成窗口函数：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)
子查询去重后聚合，性能和索引怎么配？
子查询本身不产生额外开销，但DISTINCT或窗口函数需要排序或哈希，若没索引，全表扫描+临时排序会拖慢整个视图查询。
必须检查的点：
- 子查询里的
DISTINCT字段组合，是否有对应联合索引？比如DISTINCT user_id, order_id需索引(user_id, order_id) - 窗口函数中的
PARTITION BY和ORDER BY字段，同样需要覆盖索引，否则ROW_NUMBER()会触发大量磁盘排序 - PostgreSQL 和 SQL Server 对子查询内
DISTINCT的物化策略不同：前者常自动优化为哈希去重，后者可能更倾向排序，索引影响更大
别在子查询里漏掉业务关键字段，否则聚合结果不可信
子查询去重时只选必要字段，但漏掉会影响后续聚合的准确性。比如想统计“每个用户最近一次下单金额”，子查询里如果只写SELECT DISTINCT user_id FROM orders，那就丢失了amount和created_at，根本没法取最新一笔。
正确做法是让子查询输出完整可用的最小行集：
SELECT
user_id,
MAX(amount) AS latest_amount
FROM (
SELECT
user_id,
amount,
created_at,
ROW_NUMBER() OVER (
PARTITION BY user_id
ORDER BY created_at DESC
) AS rn
FROM orders
) AS ranked
WHERE rn = 1
GROUP BY user_id;
这里子查询保留了amount和created_at，外层才能做有意义的聚合。
- 子查询字段必须包含所有外层
GROUP BY和聚合函数依赖的列 - 如果下游还要关联用户姓名，子查询里就得提前
JOIN users，而不是等外层再联——否则又引入重复风险 - MySQL 8.0+ 支持CTE，可以把子查询提成
WITH deduped AS (...)，可读性更好，但执行计划本质相同
