mysql千万級のデータはページを分けて性能を調べて最適化します。

mysqlのデータ量が多い時はlimitのページを使って、ページ番号の増加に伴って、検索効率が低下します。
実験
1.直接にlimit start、countで区切り文を使う：select * from order limit start, count開始ページが比較的小さい場合、照会には性能問題がなく、それぞれ10、100、1000、10000から分ページの実行時間を見てみます。

select * from order limit 10, 20 0.016 

select * from order limit 100, 20 0.016 

select * from order limit 1000, 20 0.047 

select * from order limit 10000, 20 0.094 

開始記録の増加に伴い、時間も増加していることが分かりました。この説明は、改ページ文のlimitとスタートページのページ番号が関係しています。それでは、スタートレコードを40 wに変更してみます。select * from order limit 400000, 20 3.229 最後のページの記録を取る時間を見てください。select * from order limit 800000, 20 37.44 明らかにこの時間は耐えられないです。
そこから私たちも二つのことをまとめることができます。
1）limit文の照会時間は、開始レコードの位置に比例します。
2）mysqlのlimit文は便利ですが、多くの表を記録するのには不向きです。
2.limit改ページ問題の性能最適化方法
表のカバーインデックスを利用して、改ページクエリを加速します。
私達はすべて知っています。インデックスクエリを利用した文にはそのインデックス列（インデックスをカバーする）だけが含まれていれば、このような状況はすぐに調べられます。
インデックス検索を利用して最適化アルゴリズムがあり、データは検索インデックスの上にありますので、関連データアドレスを探す必要はなくなりました。またMysqlにはインデックスキャッシュもありますので、同時高の場合はキャッシュを利用したほうが効果的です。
私たちの例では、idフィールドが主キーであることを知っています。当然、デフォルトのプライマリキーインデックスが含まれています。インデックスをカバーするクエリの効果を見てみましょう。
今回は最後のページのデータを調べます。select id from order limit 800000, 20 0.2 すべての列を調べた37.44秒に対して、約100倍の速度を上げました。
もし私達もすべての列を調べたいなら、2つの方法があります。一つはid>=の形式です。もう一つはジョンを利用して、実際の状況を見てみます。SELECT * FROM order WHERE ID > =(select id from order limit 800000, 1) limit 20調査時間は0.2秒で、質の飛躍です。
別様の書き方SELECT * FROM order a JOIN (select id from order limit 800000, 20) b ON a.ID = b.id検索時間も短いです。