我找到了一篇很好的文章:SQL Server-HOW-TO:快速从martijnh1检索表的准确行数，它很好地概述了每个场景。

我需要在需要根据特定条件提供计数的地方进行扩展，当我计算出这一部分时，我会进一步更新这个答案。

与此同时，以下是文章中的细节:

方法1:

查询:

SELECT COUNT(*) FROM Transactions 

评论:

执行全表扫描。在大桌子上慢点。

方法2:

查询:

SELECT CONVERT(bigint, rows) 
FROM sysindexes 
WHERE id = OBJECT_ID('Transactions') 
AND indid < 2 

评论:

快速检索行数的方法。取决于统计数据，不准确。

运行DBCC UPDATEUSAGE(数据库)WITH COUNT_ROWS，这对于大型表可能会花费大量时间。

方法3:

查询:

SELECT CAST(p.rows AS float) 
FROM sys.tables AS tbl 
INNER JOIN sys.indexes AS idx ON idx.object_id = tbl.object_id and
idx.index_id < 2 
INNER JOIN sys.partitions AS p ON p.object_id=CAST(tbl.object_id AS int) 
AND p.index_id=idx.index_id 
WHERE ((tbl.name=N'Transactions' 
AND SCHEMA_NAME(tbl.schema_id)='dbo')) 

评论:

SQL管理工作室计算行数的方法(查看表属性、存储、行数)。非常快，但仍然是大概的行数。

方法4:

查询:

SELECT SUM (row_count) 
FROM sys.dm_db_partition_stats 
WHERE object_id=OBJECT_ID('Transactions')    
AND (index_id=0 or index_id=1); 

评论:

操作快(虽然不如方法二快)，同样重要的是，可靠。

这是一个疯狂的答案，但是如果你设置了某种复制系统(对于一个有十亿行的系统，我希望你这样做)，你可以使用一个粗略的估计器(如MAX(pk))，用这个值除以你拥有的slave数量，并行运行几个查询。

在大多数情况下，你会根据最佳键(或者我猜是主键)在slave之间划分查询，以这样的方式(我们将使用250000000作为我们的Rows / slaves):

-- First slave
SELECT COUNT(pk) FROM t WHERE pk < 250000000
-- Ith slave where 2 <= I <= N - 1
SELECT COUNT(pk) FROM t WHERE pk >= I*250000000 and pk < (I+1)*250000000
-- Last slave
SELECT COUNT(pk) FROM t WHERE pk > (N-1)*250000000

但是你只需要SQL。真是一团糟。好吧，假设你是个施虐狂。 在主服务器(或最接近的从服务器)上，你很可能需要为此创建一个表:

CREATE TABLE counter_table (minpk integer, maxpk integer, cnt integer, slaveid integer)

因此，除了让select在你的slave中运行之外，你还必须做一个插入，类似于这样:

INSERT INTO counter_table VALUES (I*25000000, (I+1)*250000000, (SELECT COUNT(pk) FROM ... ), @@SLAVE_ID)

当从服务器向主服务器上的表写入数据时，可能会遇到问题。你可能需要更多的sadis——我的意思是，有创意的:

-- A table per slave!
INSERT INTO counter_table_slave_I VALUES (...)

您最终应该拥有一个相对于第一个从机，存在于复制图所遍历路径的最后的从机。该slave现在应该拥有所有其他计数器值，并且应该拥有自己的值。但是当您完成时，可能已经添加了行，所以您必须插入另一行来补偿counter_table中记录的max pk和当前的max pk。

在这一点上，您必须执行一个聚合函数来计算总的行数，但这更容易，因为您将在最多“您拥有和更改的slave数量”的行上运行它。

如果在slave中有单独的表，则可以使用UNION来获得所需的所有行。

SELECT SUM(cnt) FROM (
    SELECT * FROM counter_table_slave_1
      UNION
    SELECT * FROM counter_table_slave_2
      UNION
    ...
  )

或者，不要那么疯狂，将数据迁移到分布式处理系统，或者使用数据仓库解决方案(这也将在未来为您提供出色的数据处理)。

请注意，这取决于复制设置的好坏。由于主要的瓶颈很可能是持久存储，如果您有糟糕的存储或隔离不良的数据存储，并且有严重的邻居噪声，那么这可能会比仅等待一个SELECT COUNT(*)…

但如果你有良好的复制，那么你的速度增益应该直接与数量或奴隶相关。事实上，如果仅运行计数查询就需要10分钟，并且您有8个slave，那么您的时间将缩短到不到几分钟。也许需要一个小时来敲定解决方案的细节。

当然，您永远不会真正得到一个惊人的准确答案，因为这种分布式解决方案引入了一些时间，可以删除和插入行，但您可以尝试在同一实例中获得一个分布式的行锁，并获得特定时刻表中行的精确计数。

实际上，这似乎是不可能的，因为您基本上只能使用sql解决方案，而且我认为您没有提供一种机制来跨多个slave立即运行一个分片和锁定的查询。如果你能控制复制日志文件…这意味着您将为此目的旋转slave，这无疑比仅在一台机器上运行count查询要慢。

这是2013年的两枚硬币。

如果SQL Server版本是2005/2008，您可以使用dmv来计算表中的行数:

-- Shows all user tables and row counts for the current database 
-- Remove is_ms_shipped = 0 check to include system objects 
-- i.index_id < 2 indicates clustered index (1) or hash table (0) 
SELECT o.name, 
 ddps.row_count 
FROM sys.indexes AS i 
 INNER JOIN sys.objects AS o ON i.OBJECT_ID = o.OBJECT_ID 
 INNER JOIN sys.dm_db_partition_stats AS ddps ON i.OBJECT_ID = ddps.OBJECT_ID 
 AND i.index_id = ddps.index_id 
WHERE i.index_id < 2 
 AND o.is_ms_shipped = 0 
ORDER BY o.NAME 

对于SQL Server 2000数据库引擎，sysindexes可以工作，但强烈建议避免在将来的SQL Server版本中使用它，因为它可能在不久的将来被删除。

示例代码摘自:如何快速轻松地获取表行计数

嗯，晚了5年，不确定这是否有帮助:

我在试着数不。在SQL Server表中使用MS SQL Server Management Studio的行，并遇到了一些溢出错误，然后我使用下面的:

select count_big(1) FROM [dbname].[dbo].[FactSampleValue];

结果:

24296650578行

如果使用插入触发器代价太大，但可以使用删除触发器，并且有一个自动递增的id，那么在对整个表进行一次计数后，将计数记为last-count和last- counts -id，

然后每天只需要为id > last- counting -id计数，将其添加到last-count中，并存储新的last- counting -id。

如果被删除记录的id <= last-count -id，删除触发器将递减last-count。

我曾经读过一些文章，说当表有很多行和很多列时，SELECT COUNT(*) FROM TABLE_NAME将会很慢。

这取决于数据库。有些方法可以加速计数，例如通过跟踪索引中的行是活的还是死的，从而允许只扫描索引来提取行数。其他的则不是，因此需要访问整个表并逐个计算活动行。对于一张大桌子来说，这两种方式都很慢。

请注意，您通常可以通过使用查询优化工具、表统计信息等提取一个良好的估计。例如，在PostgreSQL的例子中，你可以从你的表中解析explain count(*)的输出，并得到一个相当好的行数估计。这就引出了你的第二个问题。

我有一个可能包含数十亿行的表(它大约有15列)。有没有更好的方法来获得一个表的行数的精确计数?

严重吗?:-)你真的是指一个有数十亿行的表的精确计数吗?你真的确定吗?: -)

如果您真的这样做了，您可以使用触发器跟踪总数，但如果这样做了，请注意并发性和死锁。