このSELECT文のスピードが、特定のLIMITの金額で大幅に変化するのはなぜですか？

Question

は、私は、MySQLで、次の簡単なクエリを実行している：

SELECT SQL_NO_CACHE longitude, latitude FROM pins ORDER BY pin_id LIMIT 100000 

これは、約0.08秒で実行されます。しかし、LIMITを120000に上げると、完了までほぼ1秒かかります。私は前後に複数のテストを実行しました。それは非常に一貫しており、約100700回のいずれかに行くことができますが、時には遅くて速いこともあります。何が起こっているかについての任意のアイデア？

id select_type table type possible_keys key  key_len ref rows Extra 
1 SIMPLE  pins index NULL   PRIMARY 4  NULL 100000 

（とLIMIT 200000）

id select_type table type possible_keys key  key_len ref rows Extra 
1 SIMPLE  pins index NULL   PRIMARY 4  NULL 200000 

追加情報

サイズ表（LIMIT 100000で）を説明：200M
innodb_buffer_pool_size：8G
サーバーには別の200GBデータベースがあります。 1

UPDATEは、私は私のサーバーをリセットし、物事は固定されているように見えます。クエリにはLIMITに比例した時間がかかります。私はまだ何が起こったのか知りたいので、生産中には起こらない。

UPDATE 2

新たな問題があります。 phpMyAdminでクエリを実行しようとしましたが、表示されている「読み込み中」のメッセージがハングアップします。私はそれを複数回試してみましたが、phpMyAdminを通してクエリを実行できないようです。 PHPで実行することは問題ありません。

Answer 1

pin_idにインデックスがありますか？または、それはPRIMARY KEYですか？

buffer_poolは16KBのブロックで構成されています。これらは必要に応じてディスクから取得され、LRU（least-recently-used）順に削除されます（大まかに）。その後、

サーバーを再起動し、これらの操作を行います。

1. は、SELECT ... LIMIT 100000; - 何もキャッシュされていないために遅い
2. SELECT ... LIMIT 100000; - すべてのデータがキャッシュされているため高速です
3. SELECT ... LIMIT 120000; - 最後の20K行がキャッシュされないために遅い
4. SELECT ... LIMIT 120000; - すべてのデータがキャッシュされているため高速です
5. SELECT ... LIMIT 100000; - まだ高速です（まだキャッシュされています）

8GBのbuffer_poolと120000行（私が前提）は簡単に適合しているので、まだキャッシュから流出していません。 （私は他のクエリがこのテーブルまたは他のテーブルからバッファプールをいっぱいにしていると仮定していません。）

は今、あなたのテーブルには、以下のBUFFER_POOLに収まらないほど大きいと仮定することができます：

1. SELECT ... LIMIT 99999999。 - すべてキャッシュされていないために遅い
2. SELECT ... LIMIT 99999999; - もう一度ゆっくり！キャッシュから溢れたものをディスクから再ロードする必要があったため

しかし、あなたは何か言及しました...この表はわずか200Mです。それがバイトの場合、最後の選択肢のペアは適用されません。 行の場合、の場合は、、おそらく、それは8GB以上です。

しかし、あなたは別のデータベースの200GBについて言及しました。それはまた、buffer_poolから来て行く16KBのブロックです。だから、それの上の活動かもしれないあなたのテーブルのブロックを突き出ている。