COUNT(DISTINCT x) 无法阻止 JOIN 膨胀，因其仅对最终物理行去重，不修复源头重复；真正有效的是预聚合右表（如子查询 GROUP BY 关联键）或用窗口函数分层计算。
COUNT(DISTINCT x) 在多表 JOIN 后结果膨胀，不是函数失效，是它忠实地对膨胀后的物理行去重——1 行主表 × 3 行明细 = 3 行，就算 x 值相同，DISTINCT 也只看到 3 行输入，结果仍是 1；但若 x 值本该唯一却因 JOIN 引入重复值（如 user_id 被复制），COUNT(DISTINCT x) 就会虚高。
为什么 COUNT(DISTINCT) 不拦得住 JOIN 膨胀
很多人误以为 COUNT(DISTINCT) 是“智能去重”，能自动识别逻辑主键。实际上它只看最终 SELECT 列表里实际输出的每一行：COUNT(DISTINCT user_id) 统计的是 JOIN 后所有非 NULL 的 user_id 值种类数，不管这些值是不是被重复拉了 5 次。
常见错误现象：
- 查用户数，
COUNT(DISTINCT users.id)返回 1000，但实际只有 200 个用户 —— 因为users和ordersLEFT JOIN 后，每个用户被重复输出多次，而users.id值本身没变，所以 DISTINCT 结果仍是 200；真正出问题的是你用了COUNT(DISTINCT orders.user_id)，而orders.user_id有脏数据或未去重关联 - 执行计划里
rows突增几十倍，但COUNT(DISTINCT)数值却比预期小——说明重复值高度集中，掩盖了膨胀事实
先定位：到底是字段真重复，还是 JOIN 拉歪了
别急着改 SQL，用三句查询快速归因：
- 查右表关联字段是否真有重复：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 1 - 对比两个统计量：
SELECT COUNT(*) AS total_rows, COUNT(DISTINCT o.user_id) AS distinct_users FROM users u LEFT JOIN orders o ON u.id = o.user_id。如果total_rows是distinct_users的 5 倍，但业务上每个用户平均就 1–2 单，那大概率是orders表里有脏数据或漏了状态过滤 - 把 JOIN 拆开跑：
SELECT COUNT(*) FROM orders WHERE user_id IN (SELECT id FROM users)，看这个数字是否接近LEFT JOIN后的行数——如果接近，说明膨胀源就在orders侧，而非连接逻辑本身
正确写法：预聚合比硬套 DISTINCT 更可靠
想统计“每个用户有多少笔有效订单”，不要写：
SELECT COUNT(DISTINCT o.user_id) FROM users u LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid';
而应先收拢 orders：
SELECT COUNT(*) FROM users u LEFT JOIN ( SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE status = 'paid' GROUP BY user_id ) o ON u.id = o.user_id;
这样做的关键好处：
- 子查询中
GROUP BY user_id确保每用户最多一行，彻底切断膨胀链 -
WHERE status = 'paid'写在子查询内，避免无效订单参与中间计算 - 外层
COUNT(*)统计的是用户数（users行数），不是订单组合数
窗口函数替代方案：仅限需要明细行的场景
如果你必须保留每条订单明细（比如要展示订单时间、金额），又想附带用户维度聚合值（如“该用户总下单次数”），COUNT(*) OVER (PARTITION BY user_id) 是更轻量的选择：
SELECT o.order_no, o.amount, COUNT(*) OVER (PARTITION BY o.user_id) AS user_total_orders FROM orders o WHERE o.status = 'paid';
注意限制：
- MySQL 8.0+ 和 PostgreSQL 支持，但旧版 Hive / Spark SQL 可能不支持
COUNT(DISTINCT) OVER，需确认引擎能力 - 窗口函数不减少行数，只是“附加计算”，所以若后续还要
GROUP BY或DISTINCT，仍可能触发二次膨胀 - 别在窗口里直接写
COUNT(DISTINCT item_id) OVER (PARTITION BY order_id)—— 多数引擎不认，会报错
最常被忽略的一点：膨胀未必是 bug，可能是业务现实。比如一个用户真有 5 个角色、3 个收货地址，COUNT(DISTINCT user_id) 仍是 1，但 COUNT(DISTINCT address_id) 就该是 3。先分清“数据重复”和“业务多对一”，再决定用预聚合、窗口函数，还是接受那个“看起来不对”的数字。
