您是否认为在每个页面加载时从一个非常大的表（如50K行）中计算条目是个好主意？
SELECT COUNT(*) FROM table
现在我有2000行似乎很快，我没有看到页面加载有任何延迟：）
但是这张桌子应该达到50K条目...而且我很好奇它将如何加载
（ps：此页面显示行计数是私有的，在Admin界面中，不是公共的）
答案 0 :(得分：8)
如果SELECT从一个表检索，没有检索到其他列，并且没有WHERE子句，则COUNT（*）被优化为非常快速地返回。例如：
mysql> SELECT COUNT(*) FROM student;
此优化仅适用于MyISAM表，因为为此存储引擎存储了精确的行数，并且可以非常快速地访问。
正如您所说，您使用MyISAM并且您的查询是针对整个表格的，无论是1行还是100000行都无关紧要。
答案 1 :(得分：0)
正如您所说的那样，这个页面是pvt而不是公共的，我没有看到该查询和50k记录的任何问题，不应该对页面加载时间和服务器负载产生任何实际影响。
答案 2 :(得分：0)
COUNT(*)不是一项昂贵的操作，实际上只是查看索引才能返回数据。即使在50k的桌子上也应该没问题。
如果您在装载时遇到问题，那么在那一点上进行牵开和优化将非常简单。
答案 3 :(得分：0)
count(*)是O（n）所以它的性能与表中的记录数有关，50k根本不是很多，所以我认为它在管理页面上没问题。当你进入数百万count(*)肯定会变得昂贵。
答案 4 :(得分：0)
MyISAM引擎在内部存储行计数，因此在发出SELECT COUNT(*) FROM table之类的查询时，它会很快。另一方面，使用InnoDB，它需要一些时间，因为它计算实际行数。这意味着 - 更多行 - 它越慢。但是有一个技巧可以使用一个小的覆盖索引来计算表中的所有行 - 然后它很快。另一个技巧是简单地将行计数存储在相应的汇总表中。
答案 5 :(得分：0)
在MyISAM中，计数（*）被优化，当时有任何＆＃39;任何＆＃39;在哪里＆＃39;条件，所以即使有数十亿行，查询也非常快。
在分区表的情况下，如果定义分区的列上有一个简单的条件，我们可以认为它的行为方式相同（例如：计算逻辑表的几个物理表上的所有行）。但事实并非如此：它会在所考虑的物理表的所有行上循环，即使我们想要全部计算它们。例如，在这里，在分成40个表的9800万行表中，计算最后32个物理表中的行数需要5分钟。
答案 6 :(得分：-1)
可以。根据{{3}} PostgreSql将对数据库进行整个扫描以计算出计数。