MySQL百万レベルデータ量ページングクエリー方法とその最適化

方法1:データベースから提供されたSQL文を直接使用する

文スタイル:MySQLで使用可能なメソッドは、

です.

select * from table_name limit m, n;

適用シーン:データ量が少ない場合(タプル100/キログラム)

に適用

原因/欠点:全表スキャンでは、速度が遅く、データベース結果セットの戻りが不安定(ある回は1,2,3、別の回は2,1,3)である.Limitは、結果セットのm位置からn本の出力を取り出す、残りは捨てることを制限する.

方法2:プライマリ・キーまたは一意のインデックスを確立し、インデックスを利用する(ページごとに10個を仮定する)

文スタイル:MySQLでは、次の方法で使用できます.

select * from table_name where id_pk > (pageNum*10) limit m;

適応シーン:データ量が多い場合(メタグループ数が万)

に適用

原因:インデックススキャン、速度が速い.ある友人は、データが検索されたのはpkに従っていないからだと提案した.idはソートされているので、データが漏れる場合がありますが、方法3

しかありません.
方法3:インデックスベースの再ソート

文スタイル、MySQLでは次の方法が使用できます:

select * from table_name where id_pk > (pageNum * 10) order by id_pk asc limit m;

適応シーン:データ量が多い場合(メタグループ数が万)に適用する.order byの後のカラムオブジェクトはプライマリキーまたはユニークであることが好ましいので、order by操作はインデックスで除去できるが、結果セットは安定である(方法1参照)

.

原因:インデックススキャン、速度が速い.しかしMySQLのソート操作は、ascだけがdescを持っていない(descは偽物で、未来は本物のdescを作ることができて、期待...).

方法4:インデックスベースprepareの使用
1番目の疑問符はpageNum、2番目の疑問符は1ページあたりのメタグループ数を表します

文スタイル、MySQLでは次の方法が使用できます:

prepare stmt_name from select * from table_name where id_pk > (? * ?) order by id_pk asc limit m;

適応シーン:ビッグデータ量

原因:インデックススキャン、速度が速い.prepare文はまた一般的なクエリー文より少し速いです.

方法5:MySQLを利用してorder操作をサポートし、インデックスを利用して一部の元祖を迅速に位置決めし、全表スキャンを避けることができる.
例えば、1000~1019行目のメタグループ(pkはプライマリ/ユニークキー)を読む.

select * from your_table where pa >= 1000 order by pk asc limit 0,20;

方法6:サブクエリー/接続+インデックスを使用して、メタの位置をすばやく特定し、メタの位置を読み取ります.
たとえば、(idはプライマリ・キー/ユニーク・キー、青色フォント時変数)サブクエリの例を使用します.

select * from your_table where id <= 
(select id from your_table order by id desc limit ($page - 1) * $pagesize order by id desc limit $pagesize)

接続の使用例:

select * from your_table as t1
join (select id from your_table order by id desc limit ($page - 1) * $pagesize as t2 where t1.id <= t2.id order by t1.id desc limit $pagesize);

mysqlビッグデータ量はlimitでページングされ、ページ番号が大きくなるにつれてクエリー効率が低下します.