MySQL查詢隨機緩慢

我有一個查詢在vBulletin系統中運行，該查詢獲取具有圖像附件的最新線程及其第一個附件ID。MySQL查詢隨機緩慢

下面是該查詢：

SELECT thread.threadid, 
      thread.title, 
      thread.postuserid, 
      thread.postusername, 
      thread.dateline, 
      thread.replycount, 
      post.pagetext, 
      (
      SELECT attachment.attachmentid 
      FROM `vb_attachment` AS attachment 
       LEFT JOIN `vb_filedata` AS data 
        ON data.filedataid=attachment.filedataid 
      WHERE attachment.contentid=thread.firstpostid 
       AND attachment.contenttypeid=1 
       AND data.extension IN('jpg','gif','png') 
       AND data.thumbnail_filesize>0 
      ORDER BY attachmentid ASC 
      LIMIT 1 
     ) AS firstattachmentid 
FROM `vb_thread` AS thread 
    LEFT JOIN `vb_post` AS post 
     ON post.postid=thread.firstpostid 
WHERE thread.forumid IN(331, 318) 
     HAVING firstattachmentid>0 
ORDER BY thread.dateline DESC 
LIMIT 0, 5

的解釋查詢，你可以在這裏看到的結果：

enter image description here

的問題：通常查詢在0.00001秒運行，所以幾乎瞬間，但是，在創建新線程（，即使線程不是來自論壇ID 331,318,）之後，它需要40多秒（直接從MySQL GUI執行），並且甚至解釋查詢需要2秒鐘！。解釋慢速查詢顯示與索引使用相同的結果。

運行相同的查詢兩三次後，它恢復到通常的速度。

如果有人可以解釋發生了什麼，以及如何解決問題，我將不勝感激幫助。

謝謝。

來源

2013-02-21 Harutyun Drnoyan

MySQL緩存查詢的結果，以便稍後更快地返回相同查詢的結果。

添加新線程導致MySQL必須在下次運行查詢時重新生成查詢緩存。

我發現MySQL子查詢性能不佳。我用來避免子查詢的一些策略：

將查詢重組爲無子查詢的聯接。
將查詢重組爲幾個查詢。
返回您需要的更多數據，然後在應用程序中使用這些數據做一些工作。

來源

2013-02-21 09:24:13 cja

謝謝你的建議。看來查詢緩存是唯一可以解釋這一點的東西。但是，我仍然不確定，因爲「解釋」顯示子查詢只使用一行，而主查詢中只有100行，即使沒有查詢緩存，它也不應該運行得更快（至少沒有45秒）？ – 2013-02-21 12:38:11

我接受你的答案，因爲到目前爲止還沒有其他答案。無論如何，這似乎主要與MySQL表引擎，e，服務器版本等有關，所以每個人都有這樣的問題應該嘗試改變這些，看看會發生什麼。 – 2013-02-25 15:35:09

我發現MySQL子查詢的行爲比我認爲他們應該慢得多。我不知道爲什麼。我避開它們。 – cja 2013-02-25 15:42:16

MySQL查詢隨機緩慢

回答

相關問題