4

660 万行を超えるテーブルを取得しました。

trip_idwho's inという名前のフィールドがありますBINARY(16)。クエリが遅すぎる ( 0.2 seconds)。このクエリは、ほぼ 3 秒に 1 回実行されます。

trip_idばかげたことをする前に、インデックス サイズをフルから 12に下げると、違いが生じるかどうかを知りたいです。

クエリをさらに微調整しようとすると、違いはありますか?

ありがとう

編集：

クエリ:

SELECT      stop_times.stop_id
FROM        trips
LEFT JOIN   stop_times ON trips.trip_id = stop_times.trip_id
WHERE       trips.route_id  = '141'
GROUP BY    stop_times.stop_id
ORDER BY    trips.trip_headsign ASC,
            stop_times.stop_sequence ASC

trip_id BINARY(16)

route_id SMALLINT(3)

trip_headsign VARCHAR(50)

stop_sequence SMALLINT(3)

クエリの説明: クエリの説明

4

3 に答える 3

2

調査を行った後、はい、0.2秒が遅いため、問題が見つかりました。

SELECT      t.trip_headsign, st.stop_sequence, s.stop_code, s.stop_name
FROM        stop_times AS st
JOIN        stops AS s USING (stop_id)
JOIN        (   SELECT  trip_id,
                        route_id,
                        trip_headsign
                FROM    trips
                WHERE   route_id = '141'
                LIMIT   2
            ) AS t
WHERE       t.trip_id = st.trip_id
GROUP BY    st.stop_id

まず、ここでは を実行する代わりにLEFT JOIN,のJOIN方が高速です。しかし重要な点は、WHERE ステートメントで旅行のすべての結果を照合していたことです。

ただし、バスには 2 つの方向しかないため、結果を 2 つに制限するだけで済みます。現在、結果は 0.018 近くになっています。1000% 以上の改善。

于 2012-06-21T20:49:13.973 に答える
1

「Extra」列に「Using temporary」と「Using filesort」があります。

これらは、物事を改善できる確実な兆候です。これらが表示される理由は、GROUP 句と ORDER 句のためです。

最初のステップ: それらは本当に必要ですか? 端から端まで、このデータを消費する言語でそれらを並べ替える方が安価であることに気付くかもしれません。

2 番目のステップ: それでも が必要な場合は、MySQL ドキュメントのORDER BY OptimizationORDER BYを参照してください。ここでソートにインデックスが使用されていない理由は、and節が異なるためです。GROUP BYORDER BY

既成概念にとらわれずに考えてください。集計を行っていないため、グループ化は必要ないかもしれません。おそらく、すべての行をプルしてから、重複した ID を無視してください。

于 2012-06-21T17:47:33.280 に答える
0

"route" インデックスに trip_headsign を追加してみてください。ORDER BY でそれを使用しているため、mysql は実際のテーブルに移動して、route_id に一致するインデックスで見つかったすべてのレコードを取得する必要があります。Explain の Extra 列に「Using index」が表示されない場合は、MySQL が実際のテーブルに戻って追加情報を取得する必要があることを意味します。

于 2012-06-21T20:03:36.630 に答える