最近發(fā)現(xiàn)最代碼網(wǎng)站中的收到的評(píng)論，提到我的，心情被贊的查詢異常緩慢，通過(guò)nginx日志發(fā)現(xiàn)響應(yīng)時(shí)間快的在5s，慢的有13s，終于忍無(wú)可忍花時(shí)間來(lái)解決了。

執(zhí)行explain之后的截圖如下：

可以看到possible_keys中有很多是之前無(wú)用的index，并沒(méi)有按預(yù)想的多列索引status,source_user_id,type來(lái)查詢，于是果斷去掉了多余的索引，執(zhí)行explain后截圖：

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

于是修改了索引的列順序?yàn)?#xff1a;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

執(zhí)行explain后截圖

比上一次的優(yōu)化降低了一個(gè)數(shù)量級(jí)。

之后研究了下mysql索引的機(jī)制，發(fā)現(xiàn)多列索引是按建立索引的列的順序來(lái)順序過(guò)濾數(shù)據(jù)的，所以按event的業(yè)務(wù)規(guī)則來(lái)說(shuō)，肯定是先用戶來(lái)區(qū)分動(dòng)態(tài)，之后再按動(dòng)態(tài)類(lèi)型，最后再按動(dòng)態(tài)狀態(tài)來(lái)查詢，于是最終調(diào)整索引順序?yàn)?#xff1a;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

執(zhí)行explain后截圖：

可以看到rows比上一次優(yōu)化降低了一個(gè)數(shù)量級(jí)。

網(wǎng)頁(yè)點(diǎn)擊我收到的評(píng)論列表時(shí)明顯響應(yīng)要快很多。

平時(shí)多總結(jié)分享不只是對(duì)自己學(xué)到的知識(shí)的鞏固，也是可以和其他技術(shù)交流學(xué)習(xí)的機(jī)會(huì)，牛牛們可以多靜心分享下相關(guān)的經(jīng)驗(yàn)和代碼。

總結(jié)

以上是生活随笔為你收集整理的mysql百万数据根据索引查询_mysql创建多列索引查询百万表数据的性能优化经验分享...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。