0

最近、私が持っているクエリの実行速度が非常に遅く、クエリごとにほぼ1秒であることに気付きました。

クエリは次のようになります

SELECT eventdate.id、
        eventdate.eid、
        eventdate.date、
        eventdate.time、
        eventdate.title、
        eventdate.address、
        eventdate.rank、
        eventdate.city、
        eventdate.state、
        eventdate.name、
        source.link、
        タイプ、
        eventdate.img
ソースから
右アウタージョイン
（（
    SELECT event.id、
            開催日、
            users.name、  
            users.rank、
            users.eid、
            event.address、
            event.city、
            event.state、
            event.lat、
            event.`long`、
            GROUP_CONCAT（types.type SEPARATOR'|'）ASタイプ
    FROMイベントFORCEINDEX（latlong_idx）
    ユーザーを参加させるevent.uid=users.id
    JOIN types ON users.tid = types.id
    -74.36829174058と-73.64365405942の間の「長い」場所
    AND lat BETWEEN 40.35195025942 AND 41.07658794058
    AND event.date> = '2009-10-15'
    GROUP BY event.id、event.date
    ORDER BY event.date、users.rank DESC
    LIMIT 0、20
）開催日
ON eventdate.uid = source.uid
AND eventdate.date = source.date;

そして説明は

+ ---- + ------------- + ------------ + -------- + -------- ------- + ------------- + --------- + ------------------ ------------ + ------- + ----------------------------- ---- +
| id | select_type | テーブル| タイプ| possible_keys | キー| key_len | ref | 行| エクストラ|
+ ---- + ------------- + ------------ + -------- + -------- ------- + ------------- + --------- + ------------------ ------------ + ------- + ----------------------------- ---- +
| 1 | プライマリ| | すべて| NULL | NULL | NULL | NULL | 20 | |
| 1 | プライマリ| ソース| ref | iddate_idx | iddate_idx | 7 | eventdate.id、eventdate.date | 156 | |
| 2 | 派生| イベント| すべて| latlong_idx | NULL | NULL | NULL | 19500 | 一時的な使用; filesortの使用|
| 2 | 派生| タイプ| ref | eid_idx | eid_idx | 4 | active.event.id | 10674 | インデックスの使用|
| 2 | 派生| ユーザー| eq_ref | id_idx | id_idx | 4 | active.types.id | 1 | whereを使用する|
+ ---- + ------------- + ------------ + -------- + -------- ------- + ------------- + --------- + ------------------ ------------ + ------- + ----------------------------- ---- +

latlongで「forceindex」を使用してみましたが、まったく高速化されていないようです。

応答が遅くなる原因は派生テーブルですか？もしそうなら、これのパフォーマンスを改善する方法はありますか？

--------編集-------------私はそれをより読みやすくするためにフォーマットを改善しようとしました

'WHEREステートメントのみを変更して同じクエリを実行します

WHERE users.id =（
SELECT users.id
ユーザーから
WHERE uidname ='frankt1'
ユーザーによる注文。承認されたDESC、users.rank DESC
制限1）
AND日付＆gt; = '2009-10-15'
GROUPBYの日付
注文日）

そのクエリは0.006秒で実行されます

説明は次のようになります

+ ---- + ------------- + ------------ + ------- + --------- ------ + --------------- + --------- + ----------------- ------------- + ------ + ---------------- +
| id | select_type | テーブル| タイプ| possible_keys | キー| key_len | ref | 行| エクストラ|
+ ---- + ------------- + ------------ + ------- + --------- ------ + --------------- + --------- + ----------------- ------------- + ------ + ---------------- +
| 1 | プライマリ| | すべて| NULL | NULL | NULL | NULL | 42 | |
| 1 | プライマリ| ソース| ref | iddate_idx | iddate_idx | 7 | eventdate.id、eventdate.date | 156 | |
| 2 | 派生| ユーザー| const | id_idx | id_idx | 4 | | 1 | |
| 2 | 派生| イベント| 範囲| eiddate_idx | eiddate_idx | 7 | NULL | 24 | whereを使用する|
| 2 | 派生| タイプ| ref | eid_idx | eid_idx | 4 | active.event.bid | 3 | インデックスの使用|
| 3 | サブクエリ| ユーザー| すべて| idname_idx | idname_idx | 767 | | 5 | filesortの使用|
+ ---- + ------------- + ------------ + ------- + --------- ------ + --------------- + --------- + ----------------- ------------- + ------ + ---------------- +
4

1 に答える 1

1

その巨大な SQL ステートメントをクリーンアップする唯一の方法は、設計図に戻って、データベースの設計と要件を慎重に検討することです。6 つのテーブルを結合し、内部選択を使用し始めるとすぐに、信じられないほどの実行時間が予想されます。

まず、すべての id フィールドがインデックス化されていることを確認しますが、デザインが有効であることを確認することをお勧めします。SQL をどこから調べればよいかわかりません - 再フォーマットした後でも。

「インデックスを使用する」とは、使用しているテーブルを CREATE または ALTER するときに正しい指示を発行する必要があることを意味することに注意してください。たとえば、MySql 5.0 create indexを参照してください。

于 2009-10-15T23:47:25.873 に答える