8

多くの作業を行った後、私はついにかなり複雑なクエリを取得して、非常にスムーズに動作し、結果を非常に迅速に返しました。

開発とテストの両方でうまく実行されていましたが、現在、テストはかなり遅くなっています。開発で0.06秒かかり、テストでもほぼ同じだったExplainクエリは、テストでは7秒になりました。

説明は少し異なりますが、なぜこれが開発者からの説明になるのかわかりません

-+ --------- + ------------------------------ + ------ + ------------------------------
--- +
| id | select_type | テーブル| タイプ| possible_keys | 鍵
 | key_len | ref | 行| 追加
   |
+ ---- + ------------- + ------------ + -------- + -------- ----------------- + ------------
-+ --------- + ------------------------------ + ------ + ------------------------------
--- +
| 1 | プライマリー| | すべて| NULL | ヌル
 | NULL | NULL | 5 |
   |
| 1 | プライマリー| チケット| ref | biddate_idx | biddate_idx
 | 7 | showsdate.bid、showsdate.date | 78 |
   |
| 2 | 派生| ショー| すべて| biddate_idx、latlong_idx | ヌル
 | NULL | NULL | 3089 | 一時的な使用; filesoの使用
rt |
| 2 | 派生| ジャンル| ref | bandid_idx | bandid_idx
 | 4 | activehw.shows.bid | 2 | インデックスの使用
   |
| 2 | 派生| アーティスト| eq_ref | bid_idx | bid_idx
 | 4 | activehw.genres.bid | 1 | 場所を使用する
   |
+ ---- + ------------- + ------------ + -------- + -------- ----------------- + ------------

とテストで

| id | select_type | テーブル| タイプ| possible_keys | キー| key_len | ref | 行| エクストラ|
+ ---- + ------------- + ------------ + -------- + -------- ----------------- + ------------- + --------- + -------- ---------------------- + -------- + ------------------ ---------------------------- +
| 1 | プライマリー| | すべて| NULL | NULL | NULL | NULL | 5 | |
| 1 | プライマリー| チケット| ref | biddate_idx | biddate_idx | 7 | showsdate.bid、showsdate.date | 78 | |
| 2 | 派生| ジャンル| インデックス| bandid_idx | bandid_idx | 139 | NULL | 531281 | インデックスを使用します。一時的な使用; filesortの使用|
| 2 | 派生| アーティスト| eq_ref | bid_idx | bid_idx | 4 | activeHW.genres.bid | 1 | |
| 2 | 派生| ショー| eq_ref | biddate_idx、latlong_idx | biddate_idx | 7 | activeHW.artists.bid | 1 | whereを使用する|
+ ---- + ------------- + ------------ + -------- + -------- ----------------- + ------------- + --------- + -------- ---------------------- + -------- + ------------------ ---------------------------- +
セットで5行(6.99秒)

クエリはまったく同じですが、テーブルの順序は異なります。これが速度低下の原因になりますか?もしそうなら、私はそれをどのように修正しますか?開発者はWindowsであり、テストはcentOsです。どちらも同じバージョンのmysql5.0を実行しており、私が言ったように、テストは完全に実行されており、データベースに構造的な変更を加えていません。

mysqlcheckを実行したところ、すべてのテーブルが正常に戻ってきました。

4

5 に答える 5

5

最初の計画は でインデックスを使用しませんshows

このインデックスが役立つと確信している場合は、強制的に実行してください。

SELECT ...
FROM ..., shows FORCE INDEX (biddate_idx) , ...
WHERE ...

その間、テーブルの統計を収集します。

于 2009-02-26T16:17:49.097 に答える
3

統計を再生成し、すべてのテーブルのインデックスを再構築して、問題が解決するかどうかを確認します。それが、計画が異なる理由である可能性があります。

他にも多くの可能性があります (メモリ、ディスク、OS の違い、その他の負荷など)。

于 2009-02-26T16:13:45.500 に答える
0

新しく構築されたマスターが、古いマスター(電力が少ない)がほんの一瞬で完了したのと同じクエリを実行するのに数分かかるという非常によく似た問題が発生しました。クエリ内の2つのmyisamテーブルでrepairtableをすばやく実行しました。これで、新しいマスターが少なくとも古いものと同じ速度でクエリを実行します。

ありがとう!

于 2009-05-29T08:35:27.083 に答える
0

これらが同じクエリからのものであると確信していますか? 説明はわずかに異なるだけでなく、かなりの違いがあります。

  1. WHERE 句が異なるテーブルにヒットしている (開発中のアーティスト、テスト中のショー)
  2. ジャンルでヒットする行数は異なります (開発では 2、テストでは 531281)。
  3. 1 番目と 2 番目の間のその他のさまざまな違いについて説明します (主に EXTRA のもの)。
于 2009-02-26T16:21:55.030 に答える