Dlaczego wartości większe od równych mają wpływ na WYBÓR MySQL?

Question

Mam duży tabelę MyISAM. Zbliża się do miliona wierszy. Jest to w zasadzie lista przedmiotów i trochę informacji na ich temat.

Istnieją dwa indeksy:

• pierwotne: identyfikator poz
• data (data) i kol (int).

uruchomić dwa zapytania:

SELECT * FROM table WHERE date = '2011-02-01' AND col < 5 LIMIT 10 

SELECT * FROM table WHERE date < '2011-02-01' AND col < 5 LIMIT 10 

Pierwszy wykończenie ~ 0,0005 sekund, a drugą w ~ 0,05 sekundy. To jest różnica 100X. Czy to niesłuszne, że obie te rzeczy działają z mniej więcej taką samą prędkością? Nie bardzo rozumiem wskaźniki. Jak mogę przyspieszyć drugie zapytanie?

Answer 1

Niezależnie od Mysql sprowadza się to do podstawowej teorii algorytmów.

Większy niż i mniej niż operacje na dużym zestawie są wolniejsze niż operacje tożsamości. Z dużym zbiorem danych idealną strukturą danych do określania wartości mniejszej lub większej jest drzewo z równoważeniem własnym (binarne lub n-drzewo). Na drzewie z samoczynnym zbalansowaniem najgorszym scenariuszem dla znalezienia wszystkich mniej/większych jest log n.

Idealną strukturą danych do sprawdzania tożsamości jest hashtable. Wydajność hashtables jest ogólnie O (1) również ustalony czas. Obiekt hashtable nie jest jednak dobry na większe/mniej.

Ogólnie dobrze zbalansowane drzewo jest tylko trochę mniej wydajne niż hashtable (w ten sposób Haskell ucieka z użyciem drzewa na hashtables).

Zatem irregardless co Mysql robi jej nie dziwi fakt, że <,> jest wolniejszy niż =

Old Odpowiedź poniżej:

Ponieważ pierwsza jest jak Hashtable odnośnika ponieważ jego '=' (szczególnie jeśli twój indeks jest hashtable) będzie on szybszy niż drugi, który może działać lepiej z indeksem drzewiastym.

Ponieważ MySql pozwala skonfigurować format indeksu, możesz spróbować zmienić to, ale jestem raczej pewien, że pierwszy zawsze będzie działał szybciej niż drugi.

Answer 2

Pierwsza wykonuje przeszukiwanie danych, gdy jako druga przechodzi skanowanie. Skany są zawsze droższe niż poszukiwania, stąd różnica czasu.

W ten sposób skanowanie oznacza przeglądanie wszystkich stron książki, w której poszukiwanie przeskakuje bezpośrednio na numer strony.

Mam nadzieję, że to może pomóc.

Answer 3

Zakładam, że masz indeks w kolumnie daty. Pierwsza kwerenda korzysta z indeksu, druga kwerenda prawdopodobnie wykonuje skanowanie liniowe (przynajmniej część danych). Bezpośrednie pobieranie jest zawsze szybsze niż skanowanie liniowe.

Answer 4

MySQL przechowuje domyślnie swoje indeksy w BTREE. Brak ogólnego skrótu.

Krótka odpowiedź na różnicę wydajności polega na tym, że formularz < ocenia więcej węzłów niż formularz =.

Indeks że masz na nie (data kol) przechowuje wartości mniej więcej jak w książce telefonicznej:

2011-01-01, col=1, row_ptr 
2011-01-01, col=2, row_ptr 
2011-01-01, col=3, row_ptr 
etc... 
2011-02-01, col=1, row_ptr 
2011-02-01, col=2, row_ptr 
2011-02-01, col=3, row_ptr 
etc... 
2011-02-02, col=1, row_ptr 
2011-02-02, col=2, row_ptr 
etc... 

... w porządku rosnącym posortowane węzły drzewo rozmiarze B (2011-01- 01, col = 1) < (2011-01-01, col = 2) < (2011-01-02, col = 1).

Twoje pytanie zmierza zasadniczo do ustalenia różnicy między:

1. Znajdź wszystkie numery telefonów z nazwiskiem „Smith” i imię zaczynające się od „A”
2. Znajdź wszystkie numery telefonów, które przychodzą przed "Smith" i imię zaczynające się od "A".

Powinno być oczywiste, dlaczego # 1 jest o wiele szybszy niż # 2.

Istnieją również rozważania dotyczące wydajności transferu pamięci/dysku i alokacji sterty (= czy WAY ma mniej transferów niż <), które stanowią nieistotną ilość czasu, ale w dużej mierze zależą od dystrybucji danych i określonej lokalizacji rekord klucza 2011-02-01, col = min (col).

• [1] http://en.wikipedia.org/wiki/B-tree
• [2] http://forge.mysql.com/wiki/MySQL_Internals_MyISAM
• [3] http://forge.mysql.com/wiki/MySQL_Internals_InnoDB