使用EXPLAIN輸出優化緩慢的MySQL查詢

Question

以下查詢需要6.6秒來運行，併產生26行。

EXPLAIN結果是'ref'類型的兩個SIMPLE查詢，使用鍵掃描23行和48行。

表f有1000行，表m有42000行。

 
seltype table type keys     key     keylen ref    rows filtered extra 

SIMPLE f  ref PRIMARY,    forum_site_id  4  const   23 100.00 Using where; Using temporary; Using filesort 
        forum_site_id, 
        forums_flag_list_new_posts 

SIMPLE m  ref forum_msg_forum_id, forum_msg_forum_id 5  locali_db.f.id 48 100.00 Using where 
        forum_msg_status, 
        forum_msg_date 

下面是該查詢（相當簡單的一個）：

SELECT 

    m.id AS msg_id, 
    m.public_id AS msg_public_id, 
     more fileds of this table ... 

    f.id AS forum_id, 
    f.public_id AS forum_public_id, 
     more fileds of this table ... 

FROM 

    forum_msgs m 
    INNER JOIN forums f ON 
     m.forum_id = f.id 

WHERE 

    f.site_id = 19 
    AND f.flag_list_new_posts = 1 

    AND m.msg_date >= 1434803744 
    AND m.status <> 11 

ORDER BY 
    m.msg_date DESC 

LIMIT 
    100 

在WHERE和ORDER BY子句是類型INTEGER的和被定義爲索引中的所有字段。字段forum_id被定義爲FOREIGN KEY。

我會很高興，找出可能導致令人髮指的性能:)

Answer 1

數據庫運行在RDS上，QPS相當高（峯值高達200）。平均而言，這會導致磁盤50 IOP/s。將實例存儲類型從磁更改爲通用SSD解決了此問題。

Answer 2

您的查詢基本上是：

SELECT m.*, f.* 
FROM forum_msgs m INNER JOIN 
    forums f 
    ON m.forum_id = f.id 
WHERE f.site_id = 19 AND 
     f.flag_list_new_posts = 1 AND 
     m.msg_date >= 1434803744 AND 
     m.status <> 11 
ORDER BY m.msg_date DESC 
LIMIT 100; 

這表明了以下指標：forums(site_id, flag_list_new_posts, id)和forum_msgs(forum_id, msg_date, status)。

我不認爲有辦法繞過order by的文件排序。

Answer 3

INDEX(msg_date) 

魔法門招優化與m開始，並避免排序爲ORDER BY。

（請提供SHOW CREATE TABLE提問的性能問題時。）

但排序不昂貴的部分。昂貴的部分可能是隨機提取到m。顯然緩存很冷。

EXPLAIN估計大約1000次讀取（23 * 48），但可能嚴重低估/高估。如果m沒有被很好地緩存，那可能是1000個磁盤命中，這很容易花費6.6秒。

如果您使用的是InnoDB，innodb_buffer_pool_size應該是可用 RAM的70％左右。