我说这个问题有点晚了，但下面是你可以用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的问题，但我在分享我在需要这样的统计数据的情况下所做的事情。在我的情况下，显示大致的行是可以接受的，所以上面的工作对我来说。

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

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

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

也许有点晚，但这可能会帮助其他人的MSSQL

;WITH RecordCount AS (  SELECT      ROW_NUMBER() OVER (ORDER BY
COLUMN_NAME) AS [RowNumber]     FROM        TABLE_NAME )  SELECT
MAX(RowNumber) FROM RecordCount

这并不是一个与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语句中完成的。

我从另一个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)。

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

这是一个疯狂的答案，但是如果你设置了某种复制系统(对于一个有十亿行的系统，我希望你这样做)，你可以使用一个粗略的估计器(如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年的两枚硬币。