mysql的count優化總體上有以下注意事項：
1.任何情況下select count(*) from tablename是最優選擇；
2.儘量減少select count(*) from tablename where col = 'value』 這種查詢；
3.杜絕select count(col) from tablename的出現。
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的使用方法和效率研究》
簡單說下，就是count的時候，如果沒有where限制的話，mysql直接返回儲存有總的行數
而在有where限制的情況下，總是需要對mysql進行全表遍歷。
在mysql5下，select count(*) 和select count(id)是完全一樣的。
表裡有300萬+條記錄。
花了0.8秒，但是我用explain檢視查詢計畫時，卻發現它沒有用primiary的index，於是強制它使用主鍵索引，結果花費了7秒！
我仔細研究了一下預設時使用的索引，居然是用的乙個bit(1)上的索引，這個字段就是乙個標誌位。
想了一下，估計因為這個索引最小，基於bit(1),而主鍵是基於int(4)的，並且所有索引都能用於計算count(*),因為總是一條記錄對應乙個索引元素。
因此有乙個小技巧提供給樓主：如果你的表中有類似標誌位(比如是否邏輯刪除）的字段，那麼在其上建立乙個索引，會把count(*)的速度提高數倍。當然最好用bit(1)型別，而不是int或char(1)儲存標誌位，那樣會更慢。
mysql的count優化總結：
1.任何情況下select count(*) from tablename是最優選擇；
2.儘量減少select count(*) from tablename where col = 'value』 這種查詢；
3.杜絕select count(col) from tablename的出現。
MySQL優化之COUNT 效率
說到mysql的count 的效率，發現越說越說不清楚，乾脆寫下來，分享給大家。count 與count col 網上搜尋了下，發現各種說法都有 比如認為count col 比count 快的 認為count 比count col 快的 還有朋友很搞笑的說到這個其實是看人品的。在不加where限制條...
MySQL查詢優化之COUNT
count 聚合函式，以及如何優化使用了該函式的查詢，很可能是mysql中最容易被誤解的前10個話題之一，在網上隨便搜尋一下就能看到很多錯誤的理解，可能比我們想象的多得多。在做優化之前，先來看看count 函式的真正作用是什麼。count 的作用 count 的另外乙個作用是統計結果集的行數。當my...
MySQL優化之COUNT 效率
count 與count col 網上搜尋了下，發現各種說法都有 比如認為count col 比count 快的 認為count 比count col 快的 還有朋友很搞笑的說到這個其實是看人品的。在不加where限制條件的情況下，count 與count col 基本可以認為是等價的 但是在有wh...