意外的大執行時間與兩個相同的SQL查詢

我會感謝某人怎麼能解釋我這種情況下http://pastebin.com/YBQTwxYG，這兩個查詢幾乎相同，但第二個執行ms除了第一個近3分鐘。意外的大執行時間與兩個相同的SQL查詢

正如EXPLAIN顯示第二個查詢使用正確的索引，但第一個沒有。

我很困惑。

2016-10-22 Vitaly Volkov

請隨時將您的代碼添加到您的問題。它是你問題的一個組成部分，因此屬於那裏（並且在pastebin中很難閱讀）。乍一看，我認爲你是對的，它使用錯誤的索引（但實際上取決於你的數據，儘管我沒有看到你的數字有3分鐘的原因）。嘗試用'straight_join'替換你的'inner join'，這應該會在兩個查詢中給你相同的執行計劃。嘗試'優化表post_article，content_post，...'來重新創建你的統計。嘗試'從... ...中選擇count（*），而不對兩個查詢使用「limit 15」。 – Solarflare

一是一些格式：

SELECT c.`id`, c.`content_id`, c.`author_id`, c.`text`, c.`typotext`, 
     c.`created`, 
     p.`id`, p.`html_title`, p.`permalink`, 
     u.`id`, u.`username`, u.`first_name`, u.`last_name`, u.`avatar` 
    FROM `content_comment` AS c 
    INNER JOIN `content_post` AS p ON (c.`content_id` = p.`id`) 
    INNER JOIN `post_article` AS a ON (p.`id` = a.`content_id`) 
    LEFT OUTER JOIN `auth_user` AS u ON (c.`author_id` = u.`id`) 
    WHERE c.`deleted` IS NULL 
     AND a.`id` IS NOT NULL 
    ORDER BY c.`created` DESC 
    LIMIT 15

如果id是post_article的PRIMARY KEY，那麼它不可能是NULL。因此，測試是不必要的。

如果您打算測試auth_user。 id，則不需要LEFT。

然後檢查是否有這些複合索引：

c: INDEX(deleted, created) -- in that order 
a: INDEX(content_id, id) -- in that order

第二個查詢是不同之處在於它訪問forum_topic，而不是auth_user。看看這兩張表SHOW CREATE TABLE可能會解釋爲什麼你有不同的解釋計劃。如果不是，請檢查SHOW TABLE STATUS。

如果您需要進一步討論，請爲所有5個表提供SHOWs。

來源

2016-10-25 05:08:13

意外的大執行時間與兩個相同的SQL查詢

回答

相關問題