MYSQLのより高いLIMITオフセットがクエリの速度を低下させるのはなぜですか？

簡単なシナリオ：1600万件を超えるレコード[サイズは2GB]のテーブル。SELECTでのLIMITオフセットが高いほど、ORDER BY * primary_key *を使用するとクエリが遅くなります

そう

SELECT * FROM large ORDER BY `id`  LIMIT 0, 30 

はるかに少ない

SELECT * FROM large ORDER BY `id` LIMIT 10000, 30 

いずれにしても、注文するレコードは30件だけで、同じです。したがって、ORDER BYによるオーバーヘッドではありません。
現在、最新の30行をフェッチする場合、約180秒かかります。その単純なクエリをどのように最適化できますか？

クエリは最初のOFFSET + LIMITレコードを数える必要があるため（そしてLIMITそれらのみを使用する必要があるため）、オフセットを大きくするとクエリの速度が低下するのが普通です。この値が大きいほど、クエリの実行時間が長くなります。

OFFSET最初にレコードが異なる長さになる可能性があるため、クエリを正しく実行できません。次に、削除されたレコードからギャップが生じる可能性があります。途中で各レコードをチェックしてカウントする必要があります。

それidがテーブルPRIMARY KEYであると仮定するとMyISAM、次のトリックを使用してスピードを上げることができます：

SELECT  t.*
FROM    (
        SELECT  id
        FROM    mytable
        ORDER BY
                id
        LIMIT 10000, 30
        ) q
JOIN    mytable t
ON      t.id = q.id

この記事を参照してください：

• MySQLのORDER BY / LIMITパフォーマンス：遅い行ルックアップ

私もまったく同じ問題を抱えていました。このデータを大量に収集する必要があり、30の特定のセットではないという事実を考えると、おそらくループを実行してオフセットを30増やします。

したがって、代わりにできることは次のとおりです。

1. データのセットの最後のIDを保持します（30）（たとえば、lastId = 530）
2. 条件を追加 WHERE id > lastId limit 0,30

したがって、常にゼロのオフセットを持つことができます。パフォーマンスの向上に驚かれることでしょう。

MySQLは、10000番目のレコード（または80000番目のバイト）に直接移動することはできません。これは、そのようにパックまたは順序付けされている（または1〜10000の連続した値がある）と想定できないためです。実際にはそうかもしれませんが、MySQLはホール/ギャップ/削除されたIDがないとは想定できません。

したがって、bobsが述べたように、MySQLはid30を返す前に、10000行をフェッチする（またはのインデックスの10000番目のエントリをトラバースする）必要があります。

編集：私のポイントを説明するために

ただし、

SELECT * FROM large ORDER BY id LIMIT 10000, 30 

だろう（ER）が遅いです、

SELECT * FROM large WHERE id >  10000 ORDER BY id LIMIT 30 

だろう速い（ER） 、そして同じ結果がまったく欠けがないことを提供返していましidS（すなわち、ギャップ）。

SELECTクエリORDER BY id LIMIT X、Yを最適化する興味深い例を見つけました。3500万行あるので、行の範囲を見つけるのに2分ほどかかりました。

ここにトリックがあります：

select id, name, address, phone
FROM customers
WHERE id > 990
ORDER BY id LIMIT 1000;

取得した最後のIDのWHEREを置くだけで、パフォーマンスが大幅に向上します。私にとっては2分から1秒でした:)

ここに他の興味深いトリック：http : //www.iheavy.com/2013/06/19/3-ways-to-optimize-for-paging-in-mysql/

文字列でも動作します

2つのクエリの時間のかかる部分は、テーブルから行を取得することです。論理的に言えば、LIMIT 0, 30バージョンでは、取得する必要があるのは30行だけです。ではLIMIT 10000, 30、バージョン、10000行が評価され、30行が返されます。データの読み取りプロセスでいくつかの最適化を行うことができますが、次の点を考慮してください。

クエリにWHERE句がある場合はどうなりますか？エンジンは、条件を満たすすべての行を返し、データを並べ替えて、最終的に30行を取得する必要があります。

行がORDER BYシーケンスで処理されない場合も考慮してください。どの行を返すかを決定するために、すべての適格行をソートする必要があります。

比較や数値に興味がある人のために:)

実験1：データセットには約1億行が含まれています。各行には、いくつかのBIGINT、TINYINT、および約1kの文字を含む（意図的に）2つのTEXTフィールドが含まれています。

• 青：= SELECT * FROM post ORDER BY id LIMIT {offset}, 5
• オレンジ：= @Quassnoiのメソッド。 SELECT t.* FROM (SELECT id FROM post ORDER BY id LIMIT {offset}, 5) AS q JOIN post t ON t.id = q.id
• もちろん、3番目のメソッドは... WHERE id>xxx LIMIT 0,5一定の時間であるため、ここには表示されません。

実験2：1つの行に3つのBIGINTしかないことを除いて、同じことです。

• 緑：=前の青
• 赤：=前のオレンジ