ホームページ >データベース >mysql チュートリアル >MySQL ページングのパフォーマンス調査

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

小云云オリジナル: 2017-12-08 11:52:261611ブラウズ

ページングは私たちのプログラミングでよく使用されますが、この記事では MySQL ページングのパフォーマンスについて説明し、皆様のお役に立つことを願っています。

いくつかの一般的なページングメソッド:

1. エスカレーターメソッド

エスカレーターメソッドは通常、ナビゲーションで前ページ/次ページモードのみを提供し、一部の製品ではそれさえ提供しません。 page 関数は「more/more」メソッドのみを提供しますが、さらに自動的に読み込むためのプルダウンメソッドもあり、技術的にはエスカレーターメソッドとして要約できます。
エスカレーター方式は、技術的な実装という点では比較的シンプルで効率的です。現在のページの最後の項目のオフセットに基づいてさらに 1 ページ進みます。 SQL として書かれると、

SELECT*FROMLIST_TABLEWHEREid> offset_id LIMIT n;

1. エレベーターメソッド

のような別のデータ取得メソッドが、1,2 などの正確なページめくりメソッドとして製品に反映されます。 ,3...n、同時にユーザーはナビゲーションのページ n に直接入力することもできます。中国ではほとんどの場面でエレベーターが使用されていますが、エレベーターの技術導入コストは比較的高くなります。

MySQL では、ストレージエンジン実装の観点から、通常 b ツリーと呼ばれるのは b+tree です。

エレベーター方式を使用する場合、ユーザーが n 番目のページをめくるように指定した場合、その位置を指定する直接的な方法はなく、1 階から 1 つずつカウントしてスキャンして count*page する必要があります。その後、実際にデータ収集が開始されるため、効率は高くありません。

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

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

//分页实体
structFinanceDcPage{
1:i32 pageSize,//页容量
2:i32 pageIndex,//当前页索引
}

次に、クエリの総数をフロントエンドに返す必要があります-end;

SELECTCOUNT(*)FROMmy_tableWHEREx= y ORDERBYid;

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

SELECT*FROMmy_tableWHEREx= y ORDERBYdate_colLIMIT (pageIndex - 1)* pageSize, pageSize;

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

//分页实体
structFinanceDcPage{
1:i32 pageSize,//页容量
2:i32 pageIndex,//当前页索引
3:i32 pageTotal,//总页数
4:i32 totalRecod,//总条数
}

従来のクエリ方法では、リクエストごとに pageIndex 値のみが変化します。つまり、limit オフセット、limit 0、10 などの num

のオフセットです。 ,10; ....limit10000,10;

上記の変更により、各クエリの実行時間にばらつきが生じます。たとえば、limit10000,10 の場合、10010 の読み取りが必要になります。データを入力して、必要な 10 個のデータを取得します。

最適化手法

従来の手法では、プログラムが多くの不要なデータを走査することが効率化の鍵であることがわかりました。重要なポイントを見つけたら、ここから始めてください。

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

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

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

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

従来の方法で十分ですが、最適化も必要な場合があります。例:

orderby optimization

SELECT*FROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5

このステートメントでは ORDERBY キーワードが使用されているため、自動インクリメント ID を並べ替える場合は、何を並べ替えるかが非常に重要です。ステートメントがインデックスである場合、またはインデックスでない場合でも、ステートメントを最適化する必要があります。

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

SELECT*FROMpa_dc_flowINNERJOIN(SELECTidFROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5)ASpa_dc_flow_idUSING(id);

以下は 2 つの SQL の説明です

この図から、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*fromaorderbysubject_code//用不上索引
selectidfromaorderbysubject_code//能用上索引
selectsubject_codefromaorderbysubject_code//能用上索引
select*fromawheresubject_code= XX orderbysubject_code//能用上索引

意思是说order by 要避免使用文件系统排序，要么把order by的字段出现在select后，要么使用order by字段出现在where 条件里，要么把order by字段与where条件字段建立复合索引！

第二条sql就是巧妙的利用第二种方式利用上了索引。 select id from a order bysubject_code，这种方式

count优化

当数据量非常大时，其实可以输出总数的大概数据，利用explain语句，他并没有真正去执行sql，而是进行的估算。

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

関連記事