? ? ?之前用mysql一直也沒覺得有特別慢的感覺，最近發現新開發的系統有個頁面打開速度非常慢，有時候1分鐘都打不開。查了一下系統，定位到是一條sql語句執行慢造成的。該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?

? ? 粗略看一下，真沒覺得有非常嚴重的問題，只是本來該用內連接的寫成了IN。查看執行計劃結果如下：

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

| 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)

嵌套的那個查詢是用了索引的，但是外層沒有用上索引，所以導致查詢速度嚴重下降。 對比一下改成內連接后的執行計劃： +----+-------------+-------+--------+-------------------------------------------+---------------------------+---------+----------------------+------+-----------------------------------------------------------+ | 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數據庫上代碼移植過來的，所以特別去看了一下oracle的執行速度。結果在oracle上執行速度非常快，忘記看執行計劃了，但顯然是利用上索引。看來oracle的優化器做的要強大許多。 最后查看了一下自己的歷史代碼，里面還是有一些地方用到了IN。上面那個嵌套查詢里面的子查詢結果就算為空，居然也要執行很久。那如果直接寫成 IN (1)呢？結果是速度又變得很快了，這要再不快，IN條件真一無是處了。查看了一下這個的執行計劃： +----+-------------+----------+-------+---------------+---------+---------+------+------+----------------------------------------------+ | 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) 這里又用上了索引，因此速度又變快了。 總結一下，數據庫的查詢速度和索引有很大關系，正確利用索引可以有效的加快查詢速度，另外還要多用執行計劃去分析。

轉載于:https://blog.51cto.com/passover/608499

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。