2016-10-22 5 views
0

このケースをどのように説明できるのか誰かに感謝しますhttp://pastebin.com/YBQTwxYG、両方のクエリはほとんど同じですが、最初のほぼ3分を除いて2番目が実行されます。2つの同一のSQLクエリで予期しない大きな実行時間が発生する

EXPLAINは、2番目のクエリが正しいインデックスを使用していることを示していますが、最初は表示されません。

私は非常に混乱しています。まず

+1

質問には常にコードを追加してください。それはあなたの質問の不可欠な部分であり、そこに属しています(そしてペーストビンで読むのは難しいです)。一見すると、間違ったインデックスを使用していると思います(実際にあなたのデータに依存しますが、あなたの数字で3分の理由はわかりません)。 'inner join'を' straight_join'に置き換えてみてください。これにより、両方のクエリで同じ実行計画が得られるはずです。 'optimize tables post_article、content_post、...'を試して、統計を再作成してください。両方のクエリに対して 'limit 15 'を指定せずに' select count(*)from ... 'を試してください。 – Solarflare

答えて

0

いくつかの書式設定:

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 

idpost_articlePRIMARY KEYであれば、それはNULLすることはできません。したがって、テストは不要です。

auth_userをテストする場合は、 idの場合、LEFTは不要です。

その後、あなたはこれらの複合インデックスを持っていることを確認してください:それはforum_topic代わりのauth_userにアクセスすることで

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

2番目のクエリ異なっています。これらの2つのテーブルについてSHOW CREATE TABLEを見ると、異なる説明計画が得られた理由を説明することができます。そうでない場合は、SHOW TABLE STATUSをチェックしてください。

さらなる議論が必要な場合は、すべての5つのテーブルにSHOWsを指定してください。

関連する問題