MySQL ページングパフォーマンスの調査

一般的なページング方法:

1. エスカレーター方式

エスカレーター方式では通常、前のページ/次のページの 2 つのナビゲーション モードのみが提供されます。一部の製品では、前のページの機能すら提供されておらず、「続きを読む/さらに読む」方法のみが提供されています。さらに、自動的にさらに読み込むプルダウン方式もあり、技術的にはこれらはすべてエスカレーター方式として要約できます。
エスカレーター方式は、技術的な実装が比較的単純かつ効率的です。現在のページの最後の項目のオフセットに従って、1 ページ戻るだけで済みます。 SQLで書くと次のようになるかもしれません

LIST_TABLE から * を選択し、 id > offset_id LIMIT n を指定します。

1. エレベーター方式

データを取得するもう 1 つの方法は、製品内で 1、2、3...n などの正確なページめくりを提供することです。ユーザーはナビゲーションにページ数を直接入力することもできます。中国ではほとんどの場面でエレベーターが使用されていますが、エレベーターの技術的な導入コストは比較的高くなっています。

MySQL では、通常言及される b-tree は、ストレージ エンジン実装の b+tree を指します。

エレベータ方式では、ユーザーがページ n に移動するように指定しても、その場所を直接指定する方法がありません。代わりに、1 階から 1 つずつカウントし、count*page までスキャンしてから実際にデータを取得する必要があり、効率が低くなります。

従来のページング技術（エレベーター方式）

まず、フロントエンドはページングエンティティとクエリ条件を渡す必要があります

//ページングエンティティ structFinanceDcPage{
1:i32 pageSize, //ページ容量 2:i32 pageIndex, //現在のページインデックス}

次に、クエリの合計数をフロントエンドに返す必要があります。

my_table から COUNT(*) を選択し、 WHERE = y で ORDER BY id を実行します。

次に、指定されたページ数をフロントエンドに返します。

SELECT * FROM my_table WHEREx = y ORDER BY date_colLIMIT (pageIndex - 1) * pageSize, pageSize;

上記の 2 つの SQL ステートメントの結果は、フロントエンド ページング エンティティと単一ページの結果セットに返される必要があります。

//ページングエンティティ structFinanceDcPage{
1:i32 pageSize, //ページ容量 2:i32 pageIndex, //現在のページインデックス 3:i32 pageTotal, //ページ総数 4:i32 totalRecod, //レコード総数}

従来のクエリ方法では、pageIndex 値、つまり制限オフセットと num オフセットのみが各リクエストで変更されます。

たとえば、limit 0,10、limit 10,10、…、limit10000,10、などです。

上記の変更により、各クエリの実行時間にずれが生じます。オフセット値が大きいほど、必要な時間は長くなります。たとえば、limit10000,10 を使用した場合、必要な 10 個のデータ項目を取得するには、10010 個のデータ項目を読み取る必要があります。

最適化手法

従来の方法から、効率化の鍵はプログラムが大量の不必要なデータを走査することであることがわかっています。キーポイントを見つけたら、そこから始めます。

エレベーターを使用する必要がない場合は、エスカレーターを使用してパフォーマンスを向上させることができます。

しかし、ほとんどの場合、エレベーター フォームはユーザーのニーズをよりよく満たすことができるため、エレベーター フォームを最適化する他の方法を見つける必要があります。

従来の方法に基づく最適化

上記の最適化方法は、ユーザーのニーズを満たすのが困難であるか、実装が複雑すぎるため、データ量が数百万などの特に大きくない場合は、実際には上記の最適化方法を使用する必要はありません。

従来の方法で十分ですが、最適化する必要があるかもしれません。例えば：

OrderBy の最適化

pa_dc_flow から * を選択し、 subject_code で並べ替え、 DESC LIMIT 100000, 5 を指定します。

このステートメントは ORDER BY キーワードを使用するため、何をソートするかが非常に重要です。自動増分 ID をソートする場合、このステートメントを最適化する必要はありません。インデックスまたは非インデックスの場合は、最適化する必要があります。

まず、インデックスが付けられていることを確認する必要があります。そうしないと、非常に遅くなります。次に、インデックスであっても、自動インクリメント ID のように順序付けられていない場合は、次のステートメントのように書き直す必要があります。

pa_dc_flow から * を選択し、INNER JOIN を実行します (pa_dc_flow から id を選択し、subject_code で DESC LIMIT 100000, 5 で ORDER BY します)。A Spa_dc_flow_id USING (id);

以下は2つのSQL文のEXPLAINです。

図から、2 番目の SQL ではスキャンできるページ数が少なくなることがわかります。

実際、これには order by の最適化が含まれます。subject_code インデックスは最初の SQL ステートメントでは使用されません。代わりに subject_code を選択した場合は、インデックスが使用されます。以下は order by の最適化です。

order by の後のフィールドにインデックスを使用する場合は、where 条件のフィールドを含む複合インデックスを作成する必要があります。 ！つまり、orcerby の後のフィールドをインデックスでソートする必要がある場合は、where 条件のフィールドを使用して複合インデックスを作成するか、[ここで複合インデックスを作成するときは、複合インデックスの列順序 (where フィールド、order by フィールド) に注意して、左端の列の原則を満たす必要があります。その理由は、order by フィールドが where クエリ条件でカウントされるためです。 ]、またはそれ自体が where 条件で参照される必要があります。

テーブル asubject_code はインデックスを持つ通常のフィールドであり、id は自動増分主キーです。

select * from a order by subject_code // インデックスは使用されません select id from a order by subject_code // インデックスを使用できます select subject_code from a order by subject_code // インデックスを使用できます select * from a where subject_code = XX order by subject_code // インデックスを使用できます

つまり、order by ではファイル システムのソートを使用しないようにする必要があります。order by フィールドを select の後に配置するか、order by フィールドを where 条件で使用するか、order by フィールドと where 条件フィールドの複合インデックスを作成してください。

2 番目の SQL ステートメントは、2 番目の方法を巧みに使用してインデックスを活用します。 subject_codeで順序を指定してIDを選択するこのメソッド

カウント最適化

データ量が非常に多い場合、explain ステートメントを使用すると、実際におおよその合計データを出力できます。これは、SQL を実際に実行するのではなく、推定値を作成します。

要約する

上記は編集者が紹介したMySQLページングパフォーマンスの調査です。皆様のお役に立てれば幸いです。ご質問がございましたら、メッセージを残してください。編集者がすぐに返信いたします。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。