Perché l'offset LIMIT più alto di MYSQL rallenta la query?

Scenario in breve: una tabella con oltre 16 milioni di record [2 GB di dimensione]. Maggiore è l'offset LIMIT con SELEZIONA, più lenta diventa la query quando si utilizza ORDER BY * primary_key *

Così

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

richiede molto meno di

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

Questo ordina solo 30 record e lo stesso comunque. Quindi non è il sovraccarico di ORDER BY.
Ora quando si recuperano le ultime 30 righe ci vogliono circa 180 secondi. Come posso ottimizzare quella semplice query?

È normale che offset più alti rallentino la query, poiché la query deve contare i primi OFFSET + LIMITrecord (e prenderne solo LIMIT). Maggiore è questo valore, più lunga sarà la query.

La query non può andare a destra OFFSET perché, in primo luogo, i record possono avere una lunghezza diversa e, in secondo luogo, possono esserci spazi vuoti dai record eliminati. Deve controllare e contare ogni record nel suo cammino.

Supponendo che idsia uno PRIMARY KEYdi un MyISAMtavolo, puoi accelerarlo usando questo trucco:

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

Vedi questo articolo:

• Prestazioni di MySQL ORDER BY / LIMIT: ricerche in ritardo

Anch'io ho avuto lo stesso problema. Dato che vuoi raccogliere una grande quantità di questi dati e non un insieme specifico di 30, probabilmente eseguirai un ciclo e incrementerai l'offset di 30.

Quindi quello che puoi fare invece è:

1. Conserva l'ultimo ID di un set di dati (30) (ad esempio lastId = 530)
2. Aggiungi la condizione WHERE id > lastId limit 0,30

Quindi puoi sempre avere un offset ZERO. Rimarrai stupito dal miglioramento delle prestazioni.

MySQL non può andare direttamente al 10000 ° record (o all'80000 ° byte come da te suggerito) perché non può presumere che sia compresso / ordinato in questo modo (o che abbia valori continui da 1 a 10000). Anche se in realtà potrebbe essere così, MySQL non può presumere che non ci siano buchi / lacune / ID cancellati.

Quindi, come notato da bob, MySQL dovrà recuperare 10000 righe (o attraversare oltre 10000 voci dell'indice su id) prima di trovare il 30 da restituire.

EDIT : per illustrare il mio punto

Si noti che sebbene

SELECT * FROM large ORDER BY id LIMIT 10000, 30 

sarebbe lento (er) ,

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

sarebbe veloce (er) e restituirebbe gli stessi risultati a condizione che non vi siano ids mancanti (ovvero vuoti).

Ho trovato un esempio interessante per ottimizzare le query SELECT ORDER BY id LIMIT X, Y. Ho 35 milioni di file, quindi ci sono voluti circa 2 minuti per trovare un intervallo di file.

Ecco il trucco:

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

Basta inserire WHERE con l'ultimo ID ottenuto per aumentare notevolmente le prestazioni. Per me è stato da 2 minuti a 1 secondo :)

Altri trucchi interessanti qui: http://www.iheavy.com/2013/06/19/3-ways-to-optimize-for-paging-in-mysql/

Funziona anche con le stringhe

La parte che richiede tempo delle due query sta recuperando le righe dalla tabella. Logicamente parlando, nella LIMIT 0, 30versione, è necessario recuperare solo 30 righe. Nella LIMIT 10000, 30versione, vengono valutate 10000 righe e vengono restituite 30 righe. Ci può essere un po 'di ottimizzazione nel mio processo di lettura dei dati, ma considera quanto segue:

E se avessi una clausola WHERE nelle query? Il motore deve restituire tutte le righe qualificate, quindi ordinare i dati e infine ottenere le 30 righe.

Considera anche il caso in cui le righe non vengono elaborate nella sequenza ORDER BY. Tutte le righe qualificanti devono essere ordinate per determinare quali righe restituire.

Per coloro che sono interessati a un confronto e cifre :)

Esperimento 1: il set di dati contiene circa 100 milioni di righe. Ogni riga contiene diversi campi BIGINT, TINYINT e due campi TEXT (deliberatamente) contenenti circa 1k caratteri.

• Blu: = SELECT * FROM post ORDER BY id LIMIT {offset}, 5
• Arancione: = metodo di @ Quassnoi. SELECT t.* FROM (SELECT id FROM post ORDER BY id LIMIT {offset}, 5) AS q JOIN post t ON t.id = q.id
• Naturalmente, il terzo metodo ... WHERE id>xxx LIMIT 0,5non appare qui poiché dovrebbe essere un tempo costante.

Esperimento 2: cosa simile, tranne per il fatto che una riga ha solo 3 GRANDI.

• verde: = il blu prima
• rosso: = l'arancione prima