5、リミットクエリの最適化
リミットは、一般的に、これはIOの問題の多くの原因となりますFilesortsを使用する時のバックのように、ほとんど、使用する句で長い順を伴って、ページング処理で使用されます。
例：
オンデマンド：クエリ動画IDと説明、およびトピックに従ってソートは、数50から始まる5つのデータを抽出しました。
select film_id,description from sakila.film order by title limit 50,5;
結果の実装：
その実施計画を見てみては：
この操作のために、我々は一種の最適化の使用しますか？
最適化ステップ1：
我々は知っているので、操作によってインデックス化主キー列または順序を使用するには、プライマリキーによって順序付けInnoDBの論理的な順序です。あなたは、IO操作の多くを回避することができます。
select film_id,description from sakila.film order by film_id limit 50,5;
実行計画を見て
、私たちが取得する場合は、5つのレコードが500行を開始したことを、実施計画は何ですか？
explain select film_id,description from sakila.film order by film_id limit 500,5\G
私たちは未来を反転として、IO操作は、テーブルが数十数百万行のデータのを持っている場合、我々はさらに最適化されなければならないので、ゆっくりとより多くなり、バックフリップ、ますます大きくなるだろう。
最適化ステップ2
プライマリキークエリろ過次回を使用し、最後で返される主キーのレコード。（注：データ記録の大量の過剰なスキャンを避けるために）
最後の動作限界は、50 5、したがって我々は、前のレコードのインデックス値を使用して、この最適化プロセスに必要
select film_id,description from sakila.film where film_id >55 and film_id<=60 order by film_id limit 1,5;
実行計画を見る：
結論：走査線の数が同じ、実施計画が固定され、効率が非常に固定されています。
注：
ソート順と連続に主キー、列、またはいくつかの列の主キーの中間空いているが、データ5行が表示される不足データリストになる場合、連続していない場合は、追加の列の確立が列をINDEX_ID、保証自動インクリメントされ、インデックスに追加する列のデータ。
