4

サイトのストレステストとすべてが壊れていることは明らかです。

今日の問題：いくつかのページのWSOD。数時間後、1ページの問題をこのクエリに絞り込みました（願っています）。以前は1秒で実行されていました。今では>300かかります。

SELECT   jobs.posting_date                          ,
         jobs.id                                    ,
         jobs.title                                 ,
         addresses.street                           ,
         cities.name                                ,
         states.abbr                                ,
         details.target_url                         ,
         details.description_extracted AS extraction,
         COUNT(jobs_skills.skill_id)   AS skills    ,
         users.first_name
FROM     jobs
         JOIN addresses
         ON       addresses.id = jobs.address_id
         JOIN states
         ON       addresses.state_id = states.id
         JOIN cities
         ON       addresses.city_id = cities.id
         JOIN job_feed_details AS details
         ON       jobs.id = details.job_id
         LEFT JOIN jobs_skills
         ON       jobs.id = jobs_skills.job_id
         LEFT JOIN users
         ON       users.id = details.user_id
WHERE    details.moderated = 0
AND      expiration        = 0
GROUP BY jobs.id
ORDER BY jobs.posting_date DESC

実行中EXPLAIN私はこれを取得します：

id  select_type table   type    possible keys           key  key_len    ref                     rows    extra
1   SIMPLE  details ALL job_id                                      537704                              Using where; Using temporary; Using filesort
1   SIMPLE  jobs        eq_ref  PRIMARY,address_id_indexPRIMARY 4   557574_dev.details.job_id       1   Using where
1   SIMPLE  addresses   eq_ref  PRIMARY             PRIMARY     4   557574_dev.jobs.address_id      1   Using where
1   SIMPLE  states      eq_ref  PRIMARY             PRIMARY     1   557574_dev.addresses.state_id   1   Using where
1   SIMPLE  cities      eq_ref  PRIMARY             PRIMARY     4   557574_dev.addresses.city_id    1   
1   SIMPLE  jobs_skills ref     Job_skill           Job_skill   4   557574_dev.jobs.id              4   Using index
1   SIMPLE  users       eq_ref  PRIMARY             PRIMARY     3   557574_dev.details.user_id      1

見て、EXPLAIN言うことは可能ですか

  • 全表スキャンが発生している場合
  • 関連する切り込みが欠落している場合
  • どのテーブルまたは結合が非常に遅いか
  • 「遅いテーブルを見つけるための私の探求」における他の有用な情報

更新：group_by（および関連するテーブル結合）なしでクエリを再実行します。まだ一時テーブルとファイルソートが必要なので、インデックスの問題のようです。欠落しているインデックスのすべてのテーブルを調べ始めます。

4

2 に答える 2

3

どのようなインデックスを定義しましたか？

jobs.address_id、addresses.state_id、addresses.city_id、details.job_id、jobs_skills.job_id、details.user_id、jobs.posting_dateにインデックスを付けると、基になるテーブルにアクセスせずにインデックスから結合全体を実行して、インデックス付きの注文。

また、ジョブはposting_dateの順序で挿入されますか？その場合は、posting_dateではなくidで注文できます。これは、主キーであるため、より高速になります。

Explainプランは、処理の大部分がグループ化と順序付けで行われているように見えます。最後のステップでファイルソートと一時テーブルがありますが、これはかなり高価です。さらに、インデックスを使用する必要がある場所で使用しているように見えるため、すべての関連付け列にインデックスが付けられていることを確認することをお勧めします。

Explainプランでより多くのインデックスが使用され、一時的なテーブルやファイルの並べ替えがなくなるまで、サンドボックスにデータをロードしてインデックスの組み合わせで遊ぶことをお勧めします。グループ化は費用がかかる傾向があるため、最後の部分で問題が発生する可能性があります。

それは役に立ちますか？

于 2011-05-05T17:55:09.280 に答える
1

私が間違っている場合は許してください。ただし、生成された説明プランの「extra」列の下に、指定されたテーブルと使用されたキー（テーブル：アドレスとキージョブなど）にインデックスが使用されるかどうかが指定されているようです。 .address_id、インデックスは使用されません。

したがって、必要なのは、追加の列の下にある「where」が表示されている場所の列に注意することだけです。このようなテーブルの場合、インデックスの作成を検討できます。

最大のテーブルにインデックスを追加すると、明らかにパフォーマンスに最大の影響があります。そこから始めるべきだと思います。

于 2011-05-05T18:46:47.077 に答える