我曾经读过一些文章，说当表有很多行和很多列时，SELECT COUNT(*) FROM TABLE_NAME将会很慢。
我有一个可能包含数十亿行的表(它大约有15列)。有没有更好的方法来获得一个表的行数的精确计数?
在回答之前请考虑以下问题:
我正在寻找一个数据库供应商 独立的解决方案。如果是也可以 涵盖MySQL, Oracle, MS SQL Server。 但如果真的没有数据库 供应商独立的解决方案，然后我 会接受不同的解决方案吗 针对不同的数据库供应商。 我不能使用任何外部工具 这样做。我主要是在找一个 基于SQL的解决方案。 我不能规范化我的数据库设计 任何进一步的。它已经在3NF中，而且 很多代码已经写好了 围绕它。
当前回答
在SQL server 2016中，我可以检查表属性，然后选择“存储”选项卡-这给了我行数，表使用的磁盘空间，使用的索引空间等。
其他回答
您可以尝试sp_spaceused (Transact-SQL)
显示行数、磁盘数 预留空间，磁盘占用空间 表、索引视图或服务 当前数据库中的代理队列， 或显示预留的磁盘空间 并被整个数据库使用。
我不认为有一个通用的总是最快的解决方案:一些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.
使用SQL Server 2019，您可以使用APPROX_COUNT_DISTINCT，它:
返回组中唯一非空值的大致数目
医生说:
APPROX_COUNT_DISTINCT是为大数据场景而设计的 针对以下条件进行优化: 访问数百万行或更高的数据集 一个或多个具有不同值的列的聚合
还有，函数
实现保证在97%的概率内高达2%的错误率 比穷举COUNT DISTINCT操作需要更少的内存 与精确的COUNT DISTINCT操作相比，较小的内存占用不太可能将内存溢出到磁盘。
该算法背后实现了HyperLogLog。
PostgreSQL:
SELECT reltuples AS approximate_row_count FROM pg_class WHERE relname = 'table_name'
为我准备了一张很大的桌子，
SELECT COUNT(1) FROM TableLarge
花了37秒
SELECT COUNT_BIG(1) FROM TableLarge
只需要4秒钟。
