在某列上放一个索引。这应该允许优化器执行索引块的完整扫描，而不是对表的完整扫描。这将大大降低你的IO成本。看看前后的执行计划。然后用两种方法测量挂钟的时间。

我不认为有一个通用的总是最快的解决方案:一些RDBMS/版本对SELECT COUNT(*)进行了特定的优化，使用更快的选项，而其他版本只是简单的表扫描。对于第二组，您需要访问文档/支持站点，这可能需要编写一些更具体的查询，通常是以某种方式命中索引的查询。

编辑:

Here's a thought that might work, depending on your schema and distribution of data: do you have an indexed column that references an increasing value, a numeric increasing ID, say, or even a timestamp or date? Then, assuming deletes don't happen, it should be possible to store the count up to some recent value (yesterday's date, highest ID value at some recent sample point) and add the count beyond that, which should resolve very quickly in the index. Very dependent on values and indices, of course, but applicable to pretty much any version of any DBMS.

这是一个疯狂的答案，但是如果你设置了某种复制系统(对于一个有十亿行的系统，我希望你这样做)，你可以使用一个粗略的估计器(如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版本中使用它，因为它可能在不久的将来被删除。

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

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

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

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

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

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

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

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

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

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