MYSQL yüksek LIMIT ofseti sorguyu neden yavaşlatıyor?

Kısaca senaryo: 16 milyondan fazla kaydı olan [2GB boyutunda] bir tablo. SELECT ile daha yüksek LIMIT ofseti, ORDER BY * birincil_anahtarı * kullanılırken sorgu yavaşlar

Yani

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

daha az alır

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

Bu sadece 30 kayıt sipariş ediyor ve aynı şekilde. Yani ORDER BY'nin genel yükü değil.
Şimdi son 30 satırı getirirken yaklaşık 180 saniye sürüyor. Bu basit sorguyu nasıl optimize edebilirim?

Sorgunun ilk OFFSET + LIMITkayıtları geri sayması (ve yalnızca LIMITbunlardan alması ) gerektiğinden, yüksek ofsetlerin sorguyu yavaşlatması normaldir . Bu değer ne kadar yüksek olursa, sorgu o kadar uzun çalışır.

Sorgu doğrudan doğruya gidemez OFFSETçünkü ilk olarak kayıtlar farklı uzunlukta olabilir ve ikinci olarak silinen kayıtlardan boşluklar olabilir. Her kaydı kontrol etmek ve saymak gerekir.

Bir tablonun idbir olduğunu varsayarsak, bu hileyi kullanarak tabloyu hızlandırabilirsiniz:PRIMARY KEYMyISAM

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

Bu makaleye bakın:

• MySQL ORDER BY / LIMIT performansı: geç sıra aramaları

Ben de aynı problemi yaşadım. Belirli bir 30 kümesi değil, bu verilerin büyük bir miktarını toplamak istediğiniz göz önüne alındığında, muhtemelen bir döngü çalıştırıyor ve ofseti 30 oranında artırıyorsunuz.

Bunun yerine ne yapabilirsiniz:

1. Bir veri kümesinin son kimliğini tutun (30) (örn. LastId = 530)
2. Koşulu ekle WHERE id > lastId limit 0,30

Böylece her zaman bir ZERO ofsetine sahip olabilirsiniz. Performans iyileştirmesinden şaşıracaksınız.

MySQL doğrudan 10000. kayda (veya önerdiğiniz gibi 80000 bayt) gidemez, çünkü bu şekilde paketlendiğini / sipariş edildiğini (veya 1 ila 10000'de sürekli değerlere sahip olduğunu) varsayamaz. Aslında bu şekilde olsa da, MySQL hiçbir delik / boşluk / silinmiş kimlik olmadığını varsayamaz.

Dolayısıyla, bobs'un belirttiği gibi, idgeri dönecek 30'u bulmadan önce MySQL'in 10000 satır getirmesi (veya dizinin 10000. girişinden geçmesi) gerekecektir .

EDIT : benim açımdan göstermek için

Her ne kadar

SELECT * FROM large ORDER BY id LIMIT 10000, 30 

olur yavaş (er) ,

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

olacağını hızlı (er) ve aynı sonuçları hiçbir kayıp vardır şartıyla döneceğini ids (yani boşluklar).

SELECT sorgularını ORDER BY id LIMIT X, Y optimize etmek için ilginç bir örnek buldum. 35 milyon satırım var, bu yüzden bir dizi satır bulmak 2 dakika sürdü.

İşte hile:

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

Sadece NEREDE aldığınız son kimliği ile performansı çok artırın. Benim için 2 dakika ile 1 saniye arasındaydı :)

Diğer ilginç numaralar: http://www.iheavy.com/2013/06/19/3-ways-to-optimize-for-paging-in-mysql/

Dizelerle de çalışır

İki sorgunun zaman alıcı kısmı satırları tablodan almaktır. Mantıken konuşursak, LIMIT 0, 30versiyonda sadece 30 satırın alınması gerekir. In LIMIT 10000, 30sürümü, 10000 satır değerlendirilir ve 30 satır döndürülür. Veri okuma sürecimde bazı optimizasyonlar yapılabilir, ancak aşağıdakileri göz önünde bulundurun:

Sorgularda WHERE yan tümcesi varsa ne olur? Motor, hak kazanan tüm satırları döndürmeli ve ardından verileri sıralamalı ve son olarak 30 satırı almalıdır.

Ayrıca, satırların ORDER BY sırasında işlenmediği durumu da göz önünde bulundurun. Hangi sıraların döndürüleceğini belirlemek için tüm uygun satırlar sıralanmalıdır.

Bir karşılaştırma ve rakamlarla ilgilenenler için :)

Deney 1: Veri kümesi yaklaşık 100 milyon satır içerir. Her satır birkaç BIGINT, TINYINT ve yaklaşık 1k karakter içeren iki METİN alanı (kasıtlı olarak) içerir.

• Mavi: = SELECT * FROM post ORDER BY id LIMIT {offset}, 5
• Turuncu: = @ Quassnoi'nin yöntemi. SELECT t.* FROM (SELECT id FROM post ORDER BY id LIMIT {offset}, 5) AS q JOIN post t ON t.id = q.id
• Tabii ki, üçüncü yöntem, ... WHERE id>xxx LIMIT 0,5sabit zaman olması gerektiğinden burada görünmüyor.

Deney 2: Benzer bir şey, tek bir satırda sadece 3 BIGINTs var.

• yeşil: = önceki mavi
• kırmızı: = önceki turuncu