2023年09月30日 14:31:44
以下是基於我結合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+樹的資料結構和對實驗結果的推測作出的判斷，如有錯誤，懇請指正！
mysql慢查詢，處理sql語句執行速度慢問題
臨時開啟慢日誌 如重啟資料庫，還會改為預設值off，如需永久改需要修改配置檔案 show variables like slow query log 如果查詢出的值為off則需要開啟慢日誌 set global slow query log on 開啟慢日誌 設定1秒以上為慢查詢 如重啟資料庫，還會...
mysql查詢速度慢的原因 整理版
在以前的部落格中陸續記錄了有關查詢效率方面的文章。今天在整理一下，寫上自己的一些心得記錄如下 常見查詢慢的原因常見的話會有如下幾種 1 沒有索引或沒有用到索引。ps 索引用來快速地尋找那些具有特定值的記錄，所有mysql索引都以b 樹的形式儲存。如果沒有索引，執行查詢時mysql必須從第乙個記錄開始...
mysql查詢速度慢的原因 整理版
在以前的部落格中陸續記錄了有關查詢效率方面的文章。今天在整理一下，寫上自己的一些心得記錄如下 常見查詢慢的原因常見的話會有如下幾種 1 沒有索引或沒有用到索引。ps 索引用來快速地尋找那些具有特定值的記錄，所有mysql索引都以b 樹的形式儲存。如果沒有索引，執行查詢時mysql必須從第乙個記錄開始...