以下是基於我結合b+樹的資料結構和對實驗結果的推測作出的判斷，如有錯誤，懇請指正！
今天實驗了一下mysql的count()操作優化, 以下討論基於mysql5.7 innodb儲存引擎. x86 windows作業系統。
建立的表的結構如下（資料量為100萬）：
首先是關於mysql的count(*)，count(pk), count(1)哪個快的問題。
實現結果如下：
並沒有什麼區別！加上了where子句之後3個查詢的時間也是相同的，我就不貼了。
之前在公司的時候就寫過乙個select count(*) from table的sql語句，在資料多的時候非常慢。所以要怎麼優化呢？
這要從innodb的索引說起, innodb的索引是b+tree。
對主鍵索引來說：它只有在葉子節點上儲存資料，它的key是主鍵，並且value為整條資料。
對輔助程式設計客棧索引來說：key為建索引的列，value為主鍵。
這給我們兩個資訊：
1. 根據主鍵會查到整條數www.cppcns.com據
2. 根據輔助索引只能查到主鍵，然後必須通過主鍵再查到剩餘資訊。
所以如果要優化count(*)操作的話，我們需要找乙個短小的列，為它建立輔助索引。
在我的例子中就是status，雖然它的」severelity」幾乎為0.
先建立索引：alter table test1 add index (status);
然後查詢，如下圖：
可以看到，查詢時間從3.35s下降到了0.26s，查詢速度提公升近13倍。
如果索引是str這一列，結果又會是怎麼樣呢？
先建立索引:alter table test1 add index (str)
結果如下：
可以看到，時間為0.422s，也很快，但是比起status這列還是有著1.5倍左右的差距。
再大膽一點做個實驗，我把status這列的索引刪掉，建立乙個status和left(omdb,200)(這一列平均1000個字元)的聯合索引，然後www.cppcns.com看查詢時間。
建立索引：alter table test1 add index (status,omdb(200))
結果如下：
時間為1.172s
alter table test1 add index (status,imdbid);
補充！！
要注意索引失效的情況！
建立了索引後正常的的樣子：
可以看到key_len為6, extra的說明是using index.
而如果索引失效的話：
索引失效有很多種情況，比如使用函式，!=操作等，具體請參考官方文件。
對mysql沒有很深的研究，以上是基於我結合b+樹的資料結構和對實驗結果的推測作出的判斷，如有錯誤，懇請指正！
mysql的count函式優化
mysql的count優化總體上有以下注意事項 1.任何情況下select count from tablename是最優選擇 2.儘量減少select count from tablename where col value 這種查詢 3.杜絕select count col from table...
Hbase 大表快速count
第一種比較簡單，但是只適合小表進行count 1.count命令 最直接的方式是在hbase shell中執行count的命令可以統計行數。html view plain copy hbase count t1 hbase count t1 interval 100000 hbase count t...
MySQL優化之COUNT 效率
說到mysql的count 的效率，發現越說越說不清楚，乾脆寫下來，分享給大家。count 與count col 網上搜尋了下，發現各種說法都有 比如認為count col 比count 快的 認為count 比count col 快的 還有朋友很搞笑的說到這個其實是看人品的。在不加where限制條...