SQL Server中INNER JOIN关联查询时COUNT函数统计结果异常

统计值远高于实际值的核心原因非常明确：Versions表中作为关联键的Uri字段存在重复值。

• 执行INNER JOIN做Uri等值关联时，只要右表（Versions）同一个Uri对应2条及以上记录，左表（Downloads）中匹配该Uri的单条日志就会被复制为对应条数的结果行，本质是触发了非预期的局部笛卡尔积
• 举个直观例子：如果Versions表中/tool/alpha-win这个Uri同时存了2条Version映射，Downloads里1条访问该Uri的200日志，关联后会生成2行结果，最终COUNT值就会变成实际值的2倍，重复记录越多偏差越大
• 你提到Versions表附带2条样例映射，问题基本出在样例外的生产数据：要么是同Uri对应多版本的脏数据，要么是录入时重复插入了相同映射，和分组、筛选逻辑本身没有关系

先执行以下语句排查Versions表的Uri重复情况，返回结果就是所有存在重复映射的Uri，对应的match_count就是该Uri关联后导致结果膨胀的倍数：

SELECT Uri, COUNT(*) AS match_count
FROM Versions
GROUP BY Uri
HAVING COUNT(*) > 1

根据业务场景和表数据量二选一即可：

方案1：关联前对Versions表去重（通用场景） #

如果业务逻辑要求一个Uri只对应一个有效Version，先在子查询中对Versions表按Uri去重，保证关联时右表Uri唯一，从根源避免行复制：

SELECT 
  dlData.IP,
  dlData.Uri,
  verData.Version,
  COUNT(dlData.id) AS download_count -- 建议用主键计数，避免IP为null时统计漏算
FROM Downloads dlData
INNER JOIN (
  -- 按Uri分组取唯一版本，排序规则可根据业务调整，比如取最新版本、最大版本号
  SELECT Uri, Version
  FROM (
    SELECT 
      Uri, 
      Version,
      ROW_NUMBER() OVER(PARTITION BY Uri ORDER BY Version DESC) AS rn
    FROM Versions
  ) t
  WHERE rn = 1
) verData ON dlData.Uri = verData.Uri
WHERE 
  dlData.Uri LIKE '%alpha%'
  AND dlData.response = '200'
  AND dlData.datetimestamp BETWEEN '20220601 00:00:00' AND '20220602 00:00:00'
GROUP BY dlData.IP, dlData.Uri, verData.Version

方案2：先聚合Downloads数据再关联（大日志表场景优先选） #

如果Downloads表数据量较大，先对Downloads表做过滤、分组聚合得到准确的分IP、分Uri下载量，再关联Versions表取版本号，完全避免关联阶段的行膨胀，性能提升非常明显：

WITH dl_stat AS (
  SELECT 
    IP,
    Uri,
    COUNT(id) AS download_count
  FROM Downloads
  WHERE 
    Uri LIKE '%alpha%'
    AND response = '200'
    AND datetimestamp BETWEEN '20220601 00:00:00' AND '20220602 00:00:00'
  GROUP BY IP, Uri
)
SELECT 
  dl_stat.IP,
  dl_stat.Uri,
  verData.Version,
  dl_stat.download_count
FROM dl_stat
INNER JOIN (
  -- 这里同样建议加Versions去重逻辑，避免最终结果出现同IP同Uri多条重复版本记录
  SELECT Uri, Version
  FROM (
    SELECT Uri, Version, ROW_NUMBER() OVER(PARTITION BY Uri ORDER BY Version DESC) AS rn
    FROM Versions
  ) t
  WHERE rn = 1
) verData ON dl_stat.Uri = verData.Uri

• 做多表关联聚合统计时，必须保证被关联表的关联键是唯一的，否则必然出现笛卡尔积导致的统计值偏差
• COUNT统计时尽量使用表的主键/非空唯一字段做计数，不要用可空字段：比如你之前用的COUNT(IP)如果存在IP为null的日志，这类记录会被直接排除，导致统计值偏小
• 如果业务上确实要求一个Uri对应多个Version，需要补充明确的版本匹配规则（比如按时间、按版本优先级匹配），不能直接用Uri做全量等值关联

内容的提问来源于stack exchange，提问作者Walter Wojciechowski