拍拍尘土

说到MySQL的COUNT(*)的效率，发现越说越说不清楚，干脆写下来，分享给大家。

COUNT(*)与COUNT(COL)
网上搜索了下，发现各种说法都有：
比如认为COUNT(COL)比COUNT(*)快的；
认为COUNT(*)比COUNT(COL)快的；
还有朋友很搞笑的说到这个其实是看人品的。

在不加WHERE限制条件的情况下，COUNT(*)与COUNT(COL)基本可以认为是等价的；
但是在有WHERE限制条件的情况下，COUNT(*)会比COUNT(COL)快非常多；

具体的数据参考如下：


mysql> SELECT COUNT(*) FROM cdb_posts where fid = 604;
+————+
| COUNT(fid) |
+————+
| 79000 |
+————+
1 row in set (0.03 sec)

mysql> SELECT COUNT(tid) FROM cdb_posts where fid = 604;
+————+
| COUNT(tid) |
+————+
| 79000 |
+————+
1 row in set (0.33 sec)

mysql> SELECT COUNT(pid) FROM cdb_posts where fid = 604;
+————+
| COUNT(pid) |
+————+
| 79000 |
+————+
1 row in set (0.33 sec)

COUNT(*)通常是对主键进行索引扫描，而COUNT(COL)就不一定了，另外前者是统计表中的所有符合的纪录总数，而后者是计算表中所有符合的COL的纪录数。还有有区别的。

COUNT时的WHERE
这点以前就写过，详细请看《Mysql中count(*),DISTINCT的使用方法和效率研究》：http://www.ccvita.com/156.html

简单说下，就是COUNT的时候，如果没有WHERE限制的话，MySQL直接返回保存有总的行数
而在有WHERE限制的情况下，总是需要对MySQL进行全表遍历。

优化总结：
1.任何情况下SELECT COUNT(*) FROM tablename是最优选择；
2.尽量减少SELECT COUNT(*) FROM tablename WHERE COL = ‘value’ 这种查询；
3.杜绝SELECT COUNT(COL) FROM tablename WHERE COL2 = ‘value’ 的出现。
MySQL 5.1.2x rc版本索引的bug

被这个问题彻底的郁闷了，最早时候是在FreeBSD下的MySQL 5.1.24 rc版本死活用不到索引，在给SELECT 语句加上FORCE INDEX (displayorder) 之后才算勉强解决。

随后在CentOS下的MySQL 5.1.23 rc版本发现了这个问题，居然在强制FORCE INDEX依旧不起作用，在经过详细的测试之后，同时居然又出现了一个 IN (1,2,3,4) 这种语句出现的索引使用的bug。

经过百般搜索，发现MySQL 5.1.26的更新文档里有说修复了这个bug，打算升级到MySQL目前的正式版本 5.1.26，但是居然只发现了rpm包，于是彻底的郁闷了。

降级吧，又怕数据在MySQL5.0下跑起来异常，真是个头疼的问题。

各位有没有比较好的解决方案，继续需求解决方案中。

以后打死不用RC版本的MySQL了。

http://blog.sina.com.cn/s/blog_5ce87d560100id19.html