SQL中COUNT(*)返回值为何会大于表的总行数？

哈哈，这个问题我之前帮不少开发者排查过，确实有点反直觉对吧？按常理COUNT(*)就是统计表的总行数，但出现“超数”的情况，大概率是下面这几个场景导致的：

• 错误的JOIN操作引发笛卡尔积
  这是最常见的原因。当你关联多张表时，如果关联条件不严谨（比如关联字段存在大量重复值，甚至直接漏掉关联条件），就会产生笛卡尔积——两张表的行进行全组合匹配。举个例子：原表users有100行，表orders有50行，要是没写ON users.id = orders.user_id这种关联条件，JOIN后的结果会是100×50=5000行，这时候COUNT(*)自然远大于原表行数。

• 窗口函数的误用
  如果你在查询里用了窗口函数（比如OVER()子句），却没做好过滤或分组，可能会让同一行被重复统计。比如写了SELECT COUNT(*) OVER() FROM users，结果集里每一行都会带上全表的计数，要是你再对这个结果集做COUNT(*)，得到的就是「原表行数×原表行数」，肯定远超实际总行数。

• 视图/CTE包含重复数据逻辑
  如果你查询的是视图或者CTE（公共表表达式），而它们的定义里用了UNION ALL（注意和会去重的UNION不同）、重复JOIN等操作，会让返回的行数比原表多。比如视图里把同一张表UNION ALL两次，那行数直接翻倍，COUNT(*)自然也跟着翻倍。

• 临时表/中间表存在重复数据
  要是你的查询依赖临时表，而插入数据时没做去重（比如用INSERT INTO temp_table SELECT * FROM original_table重复执行了两次，或者没加DISTINCT），临时表里就会有大量重复行，这时候COUNT(*)肯定比原表行数多。

• 数据库异常（极少发生）
  某些旧版本的数据库在特殊场景下（比如MyISAM引擎并发写入时的统计误差）可能会出现计数不准确，但这种情况非常罕见，优先排查前面的业务逻辑问题。

排查小技巧：先把COUNT(*)换成SELECT *查看返回的结果集，看看是不是有大量重复行或者明显的笛卡尔积情况，很快就能定位到问题根源。

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