mysql count查詢速度很慢怎麼辦？ mysql查詢速度最佳化方案

mysql查詢速度過慢是件很令人頭疼的事，所以呢，作者特地花了一些時間為大家整理了關於mysql查詢速度的優化方案，這篇文章全是作者的個人觀點，如有疑問或錯誤歡迎交流並指正，大家一起學習進步。

MySQL 大表的count()最佳化

相關mysql影片教學推薦：《mysql教學》

寫這篇文章也是為了能幫助大家解除疑問，回歸正題，以下是基於我結合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. 根據主鍵會查到整個資料 
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個字元)的聯合索引，然後看查詢時間。 建立索引： 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 樹的資料結構和對實驗結果的推測作出的判斷，如果有不足之處，歡迎大家指正。

相關文章：

Sql server2005 最佳化查詢速度50個方法小結

提高查詢速度：SQL Server資料庫最佳化方案

以上是mysql count查詢速度很慢怎麼辦？ mysql查詢速度最佳化方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！