最近發現最代碼網站中的收到的評論，提到我的，心情被贊的查詢異常緩慢，通過nginx日志發現響應時間快的在5s，慢的有13s，終于忍無可忍花時間來解決了。

執行explain之后的截圖如下：

可以看到possible_keys中有很多是之前無用的index，并沒有按預想的多列索引status,source_user_id,type來查詢，于是果斷去掉了多余的索引，執行explain后截圖：

可以看到雖然用到了status_sourceuserid_type索引，但rows反而更大了，可以想象查詢時間還肯定會更慢吧。

于是修改了索引的列順序為：mysql> alter table javaniu_event drop index status_sourceuserid_type;

Query OK, 0 rows affected (0.19 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql> alter table javaniu_event add index sourceuserid_status_type(source_user_id, status, type);

Query OK, 0 rows affected (14.47 sec)

Records: 0 Duplicates: 0 Warnings: 0

執行explain后截圖

比上一次的優化降低了一個數量級。

之后研究了下mysql索引的機制，發現多列索引是按建立索引的列的順序來順序過濾數據的，所以按event的業務規則來說，肯定是先用戶來區分動態，之后再按動態類型，最后再按動態狀態來查詢，于是最終調整索引順序為：mysql> alter table javaniu_event drop index sourceuserid_status_type;

Query OK, 0 rows affected (0.14 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql> alter table javaniu_event add index sourceuserid_type_status(source_user_id,type,status);

Query OK, 0 rows affected (16.02 sec)

Records: 0 Duplicates: 0 Warnings: 0

執行explain后截圖：

可以看到rows比上一次優化降低了一個數量級。

網頁點擊我收到的評論列表時明顯響應要快很多。

平時多總結分享不只是對自己學到的知識的鞏固，也是可以和其他技術交流學習的機會，牛牛們可以多靜心分享下相關的經驗和代碼。