優化COUNT函數的查詢在 MySQL 中最容易被誤解的話題中能夠排進前10名，我們可以在網上搜索去了解更多過於 COUNT 優化的誤解信息。在進行優化前，理解 COUNT 到底做了什麼很重要。
COUNT 函數做什麼用？
COUNT 是一個專用的函數，通常有兩種不同的方式：計算值和數據行。值指的是非空（Non-NULL）表達式（NULL表示值缺失）。如果我們在 COUNT的參數中指定了列名或其他表達式，則 COUNT 函數是計算該表達式擁有值的次數。這讓很多人困惑，相當一部分的原因是值和 NULL 的概念是模糊的。
另一種 COUNT 的形式是簡單地計算結果集的數據行數。這是在 MySQL 知道 COUNT 函數參數的表達式不可能爲 NULL 時的計算方式。最爲典型的例子是 COUNT()，你也許會以爲這是展開數據表的全部列的一種替代形式。事實上，它會忽略了全部列而僅僅對數據行數進行記數*。
一個經常犯的錯誤是我們在 COUNT 的參數裏指定了列名然後以爲是對數據行進行計數。如果你是想獲取結果中的行數，你應該一直使用 COUNT(*)，這會使得你的查詢語句意圖更明確並且可以避免性能問題。
MyISAM 的“神奇”之處
一個常見的誤解是 MyISAM 對於 COUNT 查詢來說會非常快。MyISAM 的 COUNT 查詢確實快，但這種快的場景十分有限：COUNT()查詢並且沒有 WHERE 條件時才能達到這樣的效果，而實際這種場景很少見。MySQL 能夠對這個語句進行優化的原因是存儲引擎總是知道數據表的準確行數。如果 MySQL 知道一個列col不可能爲 NULL，它也會將 COUNT(col) 轉換爲 COUNT()來進行優化。
MyISAM在 COUNT 查詢中有 WHERE條件、或其他對值進行計數時 並沒有“神奇”之處。相比其他存儲引擎可能快也可能慢，這取決於很多其他因素。
簡單的COUNT優化
當你想要對數據行的索引覆蓋不高的情況，又需要統計所有行數量時可以採用 MyISAM 引擎的 COUNT(*)來進行優化。下面的例子使用了標準的世界數據庫去展示查找 ID 大於5的城市數量時的優化力度，你寫出的SQL 語句可能如下所示：
SELECT COUNT(*) FROM world.City WHERE ID > 5;
如果使用 SHOW STATUS 檢查查詢的話會發現掃描了4079行。而如果是採用負向條件查詢，並且減去那些 ID 小於等於5的城市數量的話，你會發現可以將掃描結果減少到5行。
SELECT (SELECT COUNT(*) FROM world.City) - COUNT(*) FROM world.City WHERE ID <= 5;
這個查詢會讀取更少的行是因爲在查詢優化階段將查詢轉換爲了常量，使用 EXPLAIN 可以看到：
| id | select_type | table | rows | Extra |
|---|---|---|---|---|
| 1 | PRIMARY | City | 6 | Using where; Using index |
| 2 | SUBQUERY | NULL | NULL | Select tables optimized way |
一個常見的問題是如何在一個查詢語句中完成對同一列的不同值的數量的查詢。例如，你想通過一條查詢語句查出不同顏色對應的數量。你不能使用諸如 SELECT COUNT(color = 'blue' OR color='red') FROM items來完成查詢，因爲這樣不會區分出不同顏色相應的數量。而你也不能將顏色放入 WHERE 條件中，例如 SELECT COUNT(*) FROM items WHERE color = 'blue' AND color = 'red'由於顏色本身是互斥的，因此可以用下面的方法解決這一問題：
SELECT SUM(IF(color = 'blue', 1, 0)) AS blue,
SUM(IF(color = 'red', 1, 0)) as red FROM items;
還有一種變通的形式是不是要 SUM，而是 COUNT，只是保證了沒有值的表達式的判決表達式是 false：
SELECT COUNT(color = 'blue' OR NULL) as blue,
COUNT(color = 'red' OR NULL) as red FROM items;
使用近似值
有時候並不需要精確的數量，這個時候就可以使用近似值。在 EXPLAIN優化器中給出的估計行數通常可以滿足這種場景，此時可以使用 EXPLAIN 來替代真實的查詢。
在很多情況下，一個準確的數量與近似值相比低效很多。一個客戶曾經要求統計他們網站的活躍用戶數量。用戶數量被緩存並每隔30分鐘更新一次。這本身就不準確，因此使用估計值是可以接受的。這個查詢使用了多個 WHERE 條件去保證不會統計非活躍用戶或默認用戶（擁有特殊的 ID）。移除這些條件，並稍微修改一下 count 操作就可以變得更高效。一個更進一步的優化是移除不必要的 DISTINCT 操作，從而移除掉一次 filesort 操作。優化後的查詢速度更快，且返回了幾乎準確的結果。
更復雜的優化
通常來說，COUNT查詢很難優化，這是因爲它通常需要統計很多行（訪問很多數據），在 MySQL 中其他可選的辦法是使用覆蓋索引。如果那還不夠的話，可能需要對整個系統應用架構進行調整了。例如考慮統計數據表，或者使用外部的緩存系統（如 Memcached）。我們往往會面臨一個類似的兩難問題：快速、準確和簡單——你只能從中選擇兩項！