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

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

在回答之前请考虑以下问题:

我正在寻找一个数据库供应商 独立的解决方案。如果是也可以 涵盖MySQL, Oracle, MS SQL Server。 但如果真的没有数据库 供应商独立的解决方案,然后我 会接受不同的解决方案吗 针对不同的数据库供应商。 我不能使用任何外部工具 这样做。我主要是在找一个 基于SQL的解决方案。 我不能规范化我的数据库设计 任何进一步的。它已经在3NF中,而且 很多代码已经写好了 围绕它。


当前回答

有没有更好的方法来获得一个表的行数的精确计数?

简单地回答你的问题,没有。

如果你需要一个独立于DBMS的方法来做这件事,最快的方法总是:

SELECT COUNT(*) FROM TableName

一些DBMS供应商可能有更快的方法,只适用于他们的系统。其中一些选项已经在其他答案中发布了。

COUNT(*)应该由DBMS(至少是任何值得PROD的DB)进行优化,所以不要试图绕过它们的优化。

On a side note: I am sure many of your other queries also take a long time to finish because of your table size. Any performance concerns should probably be addressed by thinking about your schema design with speed in mind. I realize you said that it is not an option to change but it might turn out that 10+ minute queries aren't an option either. 3rd NF is not always the best approach when you need speed, and sometimes data can be partitioned in several tables if the records don't have to be stored together. Something to think about...

其他回答

如果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版本中使用它,因为它可能在不久的将来被删除。

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

有没有更好的方法来获得一个表的行数的精确计数?

简单地回答你的问题,没有。

如果你需要一个独立于DBMS的方法来做这件事,最快的方法总是:

SELECT COUNT(*) FROM TableName

一些DBMS供应商可能有更快的方法,只适用于他们的系统。其中一些选项已经在其他答案中发布了。

COUNT(*)应该由DBMS(至少是任何值得PROD的DB)进行优化,所以不要试图绕过它们的优化。

On a side note: I am sure many of your other queries also take a long time to finish because of your table size. Any performance concerns should probably be addressed by thinking about your schema design with speed in mind. I realize you said that it is not an option to change but it might turn out that 10+ minute queries aren't an option either. 3rd NF is not always the best approach when you need speed, and sometimes data can be partitioned in several tables if the records don't have to be stored together. Something to think about...

我说这个问题有点晚了,但下面是你可以用MySQL做什么(就像我使用MySQL一样)。我在这里分享我的观察:

1) SELECT COUNT(*) AS TOTAL_ROWS FROM <TABLE_NAME>

结果 行数:508534 控制台输出:受影响的行:0发现的行:1警告:0一次查询的持续时间:0.125秒。 对于有大量行的表需要一些时间,但是行数非常精确。

2) SHOW TABLE STATUS or SHOW TABLE STATUS WHERE NAME="<TABLE_NAME>"

结果 行数:511235 控制台输出:受影响的行:0发现的行:1警告:0一次查询的持续时间:0.250秒 总结:行数不准确。

3) SELECT * FROM information_schema.tables WHERE table_schema = DATABASE();

结果 行数:507806 控制台输出:受影响的行:0发现的行:48警告:0查询一次的持续时间:1.701秒。 行数不准确。

我不是MySQL或数据库专家,但我发现对于非常大的表,你可以使用选项2或3,并得到一个“公平的想法”有多少行。

我需要获得这些行数,以便在UI上显示一些统计信息。通过上面的查询,我知道总行数超过了50万,所以我提出了显示“超过50万行”这样的统计信息,但没有显示确切的行数。

也许我没有真正回答OP的问题,但我在分享我在需要这样的统计数据的情况下所做的事情。在我的情况下,显示大致的行是可以接受的,所以上面的工作对我来说。

在SQL server 2016中,我可以检查表属性,然后选择“存储”选项卡-这给了我行数,表使用的磁盘空间,使用的索引空间等。

我远不及其他回答问题的专家,但我在从表中选择随机行(不太相关)的过程中遇到了问题,但我需要知道我的参考表中的行数来计算随机索引。使用传统的Count(*)或Count(1)可以工作,但我偶尔需要2秒才能运行查询。所以相反(对于我的表命名为'tbl_HighOrder')我使用:

Declare @max int

Select @max = Row_Count
From sys.dm_db_partition_stats
Where Object_Name(Object_Id) = 'tbl_HighOrder'

它工作得很好,在Management Studio中的查询时间为零。