MySQL の遅いクエリとクエリ再構築方法の記録

序文

スロークエリとは何か、またスロークエリを最適化するにはどうすればよいか。以下では、これら 2 つの知識ポイントに関連する知識を紹介します。

スロークエリの基礎: データアクセスの最適化

データベースから不要なデータが要求されていますか?

不要なレコードをクエリする: 解決策: クエリの後に Limit を追加する

複数のテーブルが関連付けられている場合はすべての列を返す: 解決策: 必要な列のみを取得する

常にすべての列を取得する: select * 解決策: アプリケーションが列データをキャッシュしない限り、部分的な列を取得する方がよい

同じデータの繰り返しクエリ: 解決策: 必要なときにキャッシュから取得する

MySQL は追加のレコードをスキャンしていますか?

クエリ コストは、応答時間、スキャンされた行数、返された行数に基づいて測定できます。

スキャンされる行数を減らすには、必要なレコードをカバーするインデックスを使用できます。ただし、インデックスを追加しても、合計やカウントなどの集計関数のように、スキャンされる行数が返される行数と等しくなるわけではありません。

クエリを再構築する方法

1つの複雑なクエリまたは複数の単純なクエリ

これまでは、ネットワーク通信を介したクエリの解析と最適化はコストのかかる作業であったため、データベース層で可能な限り多くの作業を行うことに重点が置かれていました。

しかし、この考え方は、接続と切断が軽量で、小さなクエリ結果を効率的に返すように設計されている MySQL には当てはまりません。現代のネットワークは、帯域幅と遅延の両方の点で以前よりもはるかに高速です。 MySQL の一部のバージョンでは、汎用サーバーでも 1 秒あたり 100,000 件を超えるクエリを実行でき、ギガビット ネットワーク カードでも 1 秒あたり 2,000 件を超えるクエリを簡単に処理できます。したがって、複数の小さなクエリを実行することは、今のところ大きな問題ではありません。

もちろん、内部スキャンと比較すると、クライアントへのデータへの応答には時間がかかるため、同じ条件では、クエリをできるだけ少なくする方がよいでしょう。

分割クエリ

SQL を使用してクエリを実行する場合、データベースへの影響を減らすために、大きなクエリを小さなクエリに分割することに注意する必要があります。一度に大きなステートメントが完了すると、大量のデータが一度にロックされ、トランザクション ログ全体がいっぱいになり、システム リソースが枯渇し、他のクエリがブロックされる可能性があります。

たとえば、データ統計を行うときに、大量の注文番号の情報を照会する必要があります。IN クエリを 1 回使用するか、パラメータ リストをカットして複数回クエリするべきでしょうか。答えは、パラメータ リストをカットして複数回クエリすることです。IN にパラメータが多すぎると、MySQL はインデックスを使用できなくなったと判断し、テーブル全体のクエリを実行する可能性があるためです。このとき、データ テーブルのデータ量が多すぎると、クエリがタイムアウトする可能性があります。

// リストを長さ L の非ビュー サブリストに分割します
静的 <T> List<List<T>> 切り詰められた(List<T> リスト、最終的な int L) {
    List<List<T>> パーツ = 新しい ArrayList<List<T>>();
    最終的な int N = list.size();
    (int i = 0; i < N; i += L) の場合 {
        パーツを追加します(新しいArrayList<T>(
            リスト.subList(i, Math.min(N, i + L)))
        );
    }
    部品を返品する。
}
リスト<Integer> 数値 = Collections.unmodifiableList(
    配列.asList(5,3,1,2,9,5,0,7)
);
List<List<Integer>> parts = chunked(numbers, 3);
System.out.println(parts); // "[[5, 3, 1], [2, 9, 5], [0, 7]]" と出力します
パーツを取得します(0).追加します(-1);
System.out.println(parts); // "[[5, 3, 1, -1], [2, 9, 5], [0, 7]]" と出力します
System.out.println(numbers); // "[5, 3, 1, 2, 9, 5, 0, 7]" を出力します (変更なし!)

クエリがテーブル全体のスキャンではなくインデックスを使用できるように、プログラムによってリストを切り捨てます。

Alibaba 開発マニュアルでは、 in 以降のコレクション要素の数を慎重に評価し、1,000 以内に抑えることを推奨しています。

リレーショナルクエリの分解

複数のテーブルの内部結合を小さなクエリに分解します。結合が 3 つのテーブルを超える場合は、禁止する必要があります。

利点は次のとおりです:

1. キャッシュがより効率的になります。
2. クエリを分解するとロック競合が軽減される
3. アプリケーション層はクエリ データをキャッシュして、データベースへの負荷を軽減できます。
4. 特に大きなテーブルの場合、主キーなどを使用したクエリは条件範囲に基づくクエリよりも効率的である可能性があるため、クエリの効率が向上します。
5. 冗長なレコードのクエリを削減できる
6. さらに、これは MySQL のネストされたループ結合を使用するのではなく、アプリケーションでハッシュ結合を実装することと同じです。シナリオによっては、ハッシュ関連付けの方がはるかに効率的です。

要約する

これで、MySQL のスロー クエリとクエリ再構築に関するこの記事は終了です。MySQL のスロー クエリとクエリ再構築に関するより関連性の高いコンテンツについては、123WORDPRESS.COM で以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。