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

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 ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。

以下もご興味があるかもしれません:
  • MySQL の集計関数 count の使用法とパフォーマンスの最適化テクニック
  • MySQLクエリのパフォーマンスに影響を与える大きなオフセットの理由と最適化の詳細な説明
  • MySQL挿入パフォーマンスを最適化する方法の例
  • MySQL パフォーマンスの包括的な最適化方法リファレンス、CPU、ファイルシステムの選択から mysql.cnf パラメータの最適化まで
  • MySQL と MariaDB の違いについての簡単な説明 (MariaDB と MySQL のパフォーマンス比較)
  • 数千万のデータを扱うMySQLのページングクエリのパフォーマンスを最適化する
  • MySQL バッチ SQL 挿入パフォーマンス最適化の詳細な説明
  • MySQL の重要なパフォーマンス インデックスの計算と最適化方法の概要
  • MySQL のデータベース パフォーマンスに影響を与える要因の説明

<<:  React を使って小さなプログラムを書くための Remax フレームワークのコンパイル プロセス分析 (推奨)

>>:  Ubuntuがネットワークに接続できない場合の解決策

推薦する

Docker を使用して開発環境を構築する方法 (Windows および Mac)

目次1. Dockerを使用する利点2. Dockerをインストールする1) LinuxにDocke...

フロントエンド JavaScript でローカルあいまい検索機能を実装する方法の例

目次1. プロジェクトの見通し2. 知識ポイントObject.assign() の使用法filter...

大規模なMySQLデータベース用のマスタースレーブシステムを構築するアイデアを共有する

今週は戦争のように忙しかったです。他人に操られているような気がします。毎日朝早く出勤して夜遅く帰り、...

TSオブジェクトのスプレッド演算子とレスト演算子の詳細な説明

目次概要オブジェクトの残り属性オブジェクトの拡張プロパティオブジェクトの浅いコピーを作成するkeyo...

Windows での MySQL 8.0.15 のインストールと設定方法のグラフィック チュートリアル

この記事では、参考までにMySQL 8.0.15のインストールと設定方法のグラフィックチュートリアル...

MySQL 8.0.21 の最新バージョンのダウンロード、インストール、設定に関する詳細なチュートリアル

1. ダウンロード1. インストールパッケージをダウンロードするMySQL ダウンロード パス: h...

ランダムロールコールテーブルを実装するためのネイティブJavaScript

この記事では、JavaScriptのランダムロールコールテーブルの具体的なコードを参考までに紹介しま...

MySQL マスタースレーブ同期メカニズムと同期遅延問題追跡プロセス

序文DBA として、仕事中に MySQL マスターとスレーブの同期遅延の問題に遭遇することがよくあり...

docker run によって起動されたコンテナがハングしてデータが失われた場合の対処方法

シナリオの説明あるシステムでは、機能サービスはdocker stack deploy xxxで起動し...

DockerでEurekaを設定する方法

ユーレカ: 1. JDKイメージを構築するEurekaコンテナを起動するjdkフォルダと必要なファイ...

Node.js でメモリ効率の高いアプリケーションを作成する方法

目次序文問題: 大きなファイルのコピーNodeJS のストリームとバッファバッファストリーム解決策 ...

MySQLでテーブルを作成し、フィールドコメントを追加する方法

コードと例を直接投稿する #テーブル作成時にコメントを記述する CREATE TABLE useri...

NextCloud プライベート クラウド ストレージ ネットワーク ディスクの構築に関する詳細なチュートリアル

Nextcloud は、オープンソースで無料のプライベート クラウド ストレージ ネットワーク ディ...

レスポンシブ Web デザインが価値のない 5 つの理由

この記事は Tom Ewer の Managewp ブログからのもので、現在人気のレスポンシブ デザ...

純粋な CSS3 で美しい入力ボックスアニメーションスタイルライブラリを実現 (テキスト入力愛)

純粋な CSS3 で実装された美しい入力ボックス アニメーション スタイル ライブラリを共有します ...