这并不是一个与dbms无关的解决方案，但至少您的客户端代码看不到区别……

创建另一个只有一行和一个整数字段N1的表T，并创建INSERT TRIGGER，只执行:

UPDATE T SET N = N + 1

还可以创建一个DELETE TRIGGER来执行:

UPDATE T SET N = N - 1

一个称职的DBMS将保证2以上操作的原子性，并且N将始终包含准确的行数，然后超级快速地简单地获得:

SELECT N FROM T

虽然触发器是特定于DBMS的，但从T中选择不是，并且您的客户端代码不需要为每个受支持的DBMS更改。

但是，如果表是INSERT或DELETE密集型的，这可能会有一些可伸缩性问题，特别是如果在INSERT/DELETE之后没有立即提交。

1这些名称只是占位符——在生产中使用更有意义的名称。

也就是说，N不能通过读和写N之间的并发事务来改变，只要读和写都是在一条SQL语句中完成的。

简单的回答是:

数据库供应商独立的解决方案=使用标准= COUNT(*) 有近似的SQL Server解决方案，但不要使用COUNT(*) =超出范围

注:

COUNT(1) = COUNT(*) = COUNT(主键)以防万一

编辑:

SQL Server示例(14亿行，12列)

SELECT COUNT(*) FROM MyBigtable WITH (NOLOCK)
-- NOLOCK here is for me only to let me test for this answer: no more, no less

1运行，5分46分钟，计数= 1,401,659,700

--Note, sp_spaceused uses this DMV
SELECT
   Total_Rows= SUM(st.row_count)
FROM
   sys.dm_db_partition_stats st
WHERE
    object_name(object_id) = 'MyBigtable' AND (index_id < 2)

2次，都在1秒内，计数= 1,401,659,670

第二个有较少的rows =错误。相同或更多取决于写入(这里的删除是按小时计算的)

我使用

select /*+ parallel(a) */  count(1) from table_name a;

我从另一个StackOverflow问题/答案得到这个脚本:

SELECT SUM(p.rows) FROM sys.partitions AS p
  INNER JOIN sys.tables AS t
  ON p.[object_id] = t.[object_id]
  INNER JOIN sys.schemas AS s
  ON s.[schema_id] = t.[schema_id]
  WHERE t.name = N'YourTableNameHere'
  AND s.name = N'dbo'
  AND p.index_id IN (0,1);

我的表有5亿条记录，上面的返回时间不到1毫秒。 与此同时,

SELECT COUNT(id) FROM MyTable

整整39分52秒!

它们产生的行数完全相同(在我的例子中，正好是519326012)。

我不知道情况是否会一直如此。

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

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

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

结果:

24296650578行

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

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

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

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

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

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