Dlaczego wyższe przesunięcie LIMIT w MYSQL spowalnia zapytanie?

Scenariusz w skrócie: tabela z ponad 16 milionami rekordów [rozmiar 2 GB]. Im większe przesunięcie LIMIT z SELECT, tym wolniejsze staje się zapytanie, gdy używa się ORDER BY * primary_key *

Więc

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

zajmuje znacznie mniej niż

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

To zamawia tylko 30 płyt i tak samo. Więc to nie jest narzut z ORDER BY.
Teraz pobieranie ostatnich 30 wierszy zajmuje około 180 sekund. Jak mogę zoptymalizować to proste zapytanie?

To normalne, że wyższe przesunięcia spowalniają zapytanie, ponieważ zapytanie musi odliczać pierwsze OFFSET + LIMITrekordy (i pobierać tylko LIMITz nich). Im wyższa jest ta wartość, tym dłużej trwa zapytanie.

Zapytanie nie może przejść od razu, OFFSETponieważ po pierwsze rekordy mogą mieć różną długość, a po drugie, mogą istnieć luki w usuniętych rekordach. Musi sprawdzić i policzyć każdy rekord w drodze.

Zakładając, że idjest PRIMARY KEYz MyISAMtabeli, można ją przyspieszyć stosując ten trick:

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

Zobacz ten artykuł:

• Wydajność MySQL ORDER BY / LIMIT: wyszukiwanie w późnych wierszach

Sam miałem ten sam problem. Biorąc pod uwagę fakt, że chcesz zebrać dużą ilość tych danych, a nie konkretny zestaw 30, prawdopodobnie uruchomisz pętlę i zwiększysz przesunięcie o 30.

Zamiast tego możesz zrobić:

1. Trzymaj ostatni identyfikator zestawu danych (30) (np. LastId = 530)
2. Dodaj warunek WHERE id > lastId limit 0,30

Więc zawsze możesz mieć przesunięcie ZERO. Będziesz zaskoczony poprawą wydajności.

MySQL nie może przejść bezpośrednio do 10000. rekordu (lub 80000 bajtu, jak sugerujesz), ponieważ nie może założyć, że jest tak spakowany / uporządkowany (lub że ma ciągłe wartości od 1 do 10000). Chociaż w rzeczywistości może tak być, MySQL nie może zakładać, że nie ma dziur / luk / usuniętych identyfikatorów.

Tak więc, jak zauważył bobs, MySQL będzie musiał pobrać 10000 wierszy (lub przejść przez 10000-te pozycje indeksu id) przed znalezieniem 30 do zwrócenia.

EDYCJA : Aby zilustrować mój punkt widzenia

Zauważ, że chociaż

SELECT * FROM large ORDER BY id LIMIT 10000, 30 

byłby wolny (er) ,

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

byłby szybszy (er) i zwróciłby te same wyniki pod warunkiem, że nie ma brakujących ids (tj. luk).

Znalazłem ciekawy przykład optymalizacji zapytań SELECT ORDER BY id LIMIT X, Y. Mam 35 milionów wierszy, więc znalezienie ich zajęło 2 minuty.

Oto sztuczka:

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

Po prostu wpisz GDZIE z ostatnim identyfikatorem, który dostałeś, aby znacznie zwiększyć wydajność. U mnie było to od 2 minut do 1 sekundy :)

Inne ciekawe sztuczki tutaj: http://www.iheavy.com/2013/06/19/3-ways-to-optimize-for-paging-in-mysql/

Działa również ze sznurkami

Czasochłonną częścią tych dwóch zapytań jest pobieranie wierszy z tabeli. Logicznie rzecz biorąc, w tej LIMIT 0, 30wersji trzeba pobrać tylko 30 wierszy. W tej LIMIT 10000, 30wersji ocenianych jest 10000 wierszy i zwracanych jest 30 wierszy. Proces odczytu danych może zostać zoptymalizowany, ale weź pod uwagę następujące kwestie:

A co by było, gdybyś miał w zapytaniach klauzulę WHERE? Silnik musi zwrócić wszystkie wiersze, które się kwalifikują, a następnie posortować dane i ostatecznie pobrać 30 wierszy.

Weź również pod uwagę przypadek, w którym wiersze nie są przetwarzane w sekwencji ORDER BY. Wszystkie kwalifikujące się wiersze muszą zostać posortowane, aby określić, które wiersze mają zostać zwrócone.

Dla zainteresowanych porównaniem i liczbami :)

Eksperyment 1: zbiór danych zawiera około 100 milionów wierszy. Każdy wiersz zawiera kilka BIGINT, TINYINT, a także dwa pola TEXT (celowo) zawierające około 1k znaków.

• Niebieski: = SELECT * FROM post ORDER BY id LIMIT {offset}, 5
• Pomarańczowy: = metoda @ Quassnoi. SELECT t.* FROM (SELECT id FROM post ORDER BY id LIMIT {offset}, 5) AS q JOIN post t ON t.id = q.id
• Oczywiście trzecia metoda ... WHERE id>xxx LIMIT 0,5nie pojawia się tutaj, ponieważ powinna to być stała czasowa.

Eksperyment 2: Podobna rzecz, z tą różnicą, że jeden wiersz ma tylko 3 BIGINT.

• zielony: = niebieski przed
• czerwony: = pomarańczowy wcześniej