COUNT(*)会溢出而COUNT_BIG()不会，因前者返回int类型（最大2147483647），超限后截断为负数；后者返回bigint（最大9223372036854775807），专为超大表设计，且溢出发生在聚合阶段，CAST无效。
为什么COUNT(*)会溢出而COUNT_BIG()不会
SQL Server 的 COUNT(*) 返回 int 类型，最大值是 2,147,483,647；一旦表行数超过这个值，查询本身不会报错，但结果会被截断为负数（如 -2147483648），造成严重误判。而 COUNT_BIG() 返回 bigint，支持高达 9,223,372,036,854,775,807 行，专为超大表设计。
注意：这不是精度问题，是类型硬限制 —— 即使你用 CAST(COUNT(*) AS bigint) 也无用，因为溢出发生在聚合阶段，转换只是对错误结果再包装。
COUNT_BIG() 的三种典型用法及适用场景
它和 COUNT() 语法完全一致，但语义更严格：
-
COUNT_BIG(*)：统计所有行（含 NULL 值行），最常用，适合快速估算总行数 -
COUNT_BIG(列名)：只统计该列非 NULL 值的行数，注意列允许 NULL 时结果可能小于COUNT_BIG(*) -
COUNT_BIG(1)：等价于COUNT_BIG(*)，写法更明确，部分团队用它强调“不关心具体列”
示例：
SELECT COUNT_BIG(*) FROM dbo.HugeLogTable;
比 COUNT(*) 多花不了多少时间，但结果可信。
执行计划里看不到扫描？别急着信 COUNT_BIG() 的结果
SQL Server 对 COUNT_BIG(*) 仍可能走索引统计信息（尤其是聚集索引或唯一索引）而非实际扫描，这意味着：
- 如果表刚大批量插入/删除，且未更新统计信息，
COUNT_BIG(*)可能返回过期值 - 执行计划中看到
Index Seek或Index Scan不代表一定准确，要看是否加了WITH (NOLOCK)或是否命中统计元数据 - 要强制精确计数，可加
OPTION (QUERYTRACEON 8649)（启用并行扫描）或在查询前执行UPDATE STATISTICS dbo.HugeLogTable WITH FULLSCAN;
简单验证方式：
DBCC SHOW_STATISTICS('dbo.HugeLogTable', 'PK_HugeLogTable_Id');
查看 rows 字段是否接近你预期的值。
替代方案：sys.dm\_db_partition_stats 比 COUNT_BIG() 快但不绝对可靠
对于只求“大致数量”的场景，查系统视图更快：
SELECT SUM(rows) FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID('dbo.HugeLogTable') AND index_id IN (0,1);
但它依赖分区统计，不是实时值，尤其在频繁 DML 的 OLTP 表中偏差可达 ±5%。真正需要强一致性时，还是得靠 COUNT_BIG(*) 配合适当的事务隔离级别（如 REPEATABLE READ）。
复杂点在于：没有银弹。你要的是快，还是准？快就用系统视图；准就用 COUNT_BIG(*) 并接受它可能阻塞或被阻塞 —— 这个权衡，往往比函数名本身更关键。
