? ? ?之前用mysql一直也沒覺得有特別慢的感覺，最近發(fā)現(xiàn)新開發(fā)的系統(tǒng)有個頁面打開速度非常慢，有時(shí)候1分鐘都打不開。查了一下系統(tǒng)，定位到是一條sql語句執(zhí)行慢造成的。該sql如下：

SELECT??

????????COUNT(1)???????????????AS?value?

??????,?document.sourceType????AS?lable?

FROM??

?????document?

WHERE?

?????document.id??

???IN??

????(SELECT??

????????????document_id?

?????FROM??

????????????subject_document??

?????WHERE?

?????????????subject_id?=?345?

?????)??

GROUP?BY??

?????document.sourceType?

? ? 粗略看一下，真沒覺得有非常嚴(yán)重的問題，只是本來該用內(nèi)連接的寫成了IN。查看執(zhí)行計(jì)劃結(jié)果如下：

+----+--------------------+------------------+------+-------------------------------------------+---------------------------+---------+------------+--------+----------------------------------------------+

| id | select_type ? ? ? ?| table ? ? ? ? ? ?| type | possible_keys ? ? ? ? ? ? ? ? ? ? ? ? ? ? | key ? ? ? ? ? ? ? ? ? ? ? | key_len | ref ? ? ? ?| rows ? | Extra ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|

+----+--------------------+------------------+------+-------------------------------------------+---------------------------+---------+------------+--------+----------------------------------------------+

| ?1 | PRIMARY ? ? ? ? ? ?| document ? ? ? ? | ALL ?| NULL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| NULL ? ? ? ? ? ? ? ? ? ? ?| NULL ? ?| NULL ? ? ? | 117287 | Using where; Using temporary; Using filesort |

| ?2 | DEPENDENT SUBQUERY | subject_document | ref ?| uk_subject_id_document_id,idx_document_id | uk_subject_id_document_id | 10 ? ? ?| const,func | ? ? ?1 | Using where; Using index ? ? ? ? ? ? ? ? ? ? |

+----+--------------------+------------------+------+-------------------------------------------+---------------------------+---------+------------+--------+----------------------------------------------+

2 rows in set (0.41 sec)

嵌套的那個查詢是用了索引的，但是外層沒有用上索引，所以導(dǎo)致查詢速度嚴(yán)重下降。 對比一下改成內(nèi)連接后的執(zhí)行計(jì)劃： +----+-------------+-------+--------+-------------------------------------------+---------------------------+---------+----------------------+------+-----------------------------------------------------------+ | id | select_type | table | type ? | possible_keys ? ? ? ? ? ? ? ? ? ? ? ? ? ? | key ? ? ? ? ? ? ? ? ? ? ? | key_len | ref ? ? ? ? ? ? ? ? ?| rows | Extra ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | +----+-------------+-------+--------+-------------------------------------------+---------------------------+---------+----------------------+------+-----------------------------------------------------------+ | ?1 | SIMPLE ? ? ?| sd ? ?| ref ? ?| uk_subject_id_document_id,idx_document_id | uk_subject_id_document_id | 5 ? ? ? | const ? ? ? ? ? ? ? ?| ?455 | Using where; Using index; Using temporary; Using filesort | | ?1 | SIMPLE ? ? ?| d ? ? | eq_ref | PRIMARY ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | PRIMARY ? ? ? ? ? ? ? ? ? | 4 ? ? ? | pscms.sd.document_id | ? ?1 | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | +----+-------------+-------+--------+-------------------------------------------+---------------------------+---------+----------------------+------+-----------------------------------------------------------+ 2 rows in set (0.05 sec) 這就可以用上索引，所以查詢速度非常快。 由于這個程序是從一個oracle數(shù)據(jù)庫上代碼移植過來的，所以特別去看了一下oracle的執(zhí)行速度。結(jié)果在oracle上執(zhí)行速度非常快，忘記看執(zhí)行計(jì)劃了，但顯然是利用上索引。看來oracle的優(yōu)化器做的要強(qiáng)大許多。 最后查看了一下自己的歷史代碼，里面還是有一些地方用到了IN。上面那個嵌套查詢里面的子查詢結(jié)果就算為空，居然也要執(zhí)行很久。那如果直接寫成 IN (1)呢？結(jié)果是速度又變得很快了，這要再不快，IN條件真一無是處了。查看了一下這個的執(zhí)行計(jì)劃： +----+-------------+----------+-------+---------------+---------+---------+------+------+----------------------------------------------+ | id | select_type | table ? ?| type ?| possible_keys | key ? ? | key_len | ref ?| rows | Extra ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| +----+-------------+----------+-------+---------------+---------+---------+------+------+----------------------------------------------+ | ?1 | SIMPLE ? ? ?| document | range | PRIMARY ? ? ? | PRIMARY | 4 ? ? ? | NULL | ? ?2 | Using where; Using temporary; Using filesort | +----+-------------+----------+-------+---------------+---------+---------+------+------+----------------------------------------------+ 1 row in set (0.00 sec) 這里又用上了索引，因此速度又變快了。 總結(jié)一下，數(shù)據(jù)庫的查詢速度和索引有很大關(guān)系，正確利用索引可以有效的加快查詢速度，另外還要多用執(zhí)行計(jì)劃去分析。

轉(zhuǎn)載于:https://blog.51cto.com/passover/608499

總結(jié)

以上是生活随笔為你收集整理的mysql严重查询速度的问题一则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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