Trochę trudno to wyjaśnić.
Kwerenda korzystająca z indeksu używa go, ponieważ indeks jest indeksem „pokrywającym”. Oznacza to, że w zapytaniu znajdują się wszystkie kolumny w indeksie. Jedyną częścią indeksu, która naprawdę jest używana efektywnie, jest warunek na latitude .
Normalnie indeks pokrycia miałby tylko kolumny wymienione w zapytaniu. Jednak klucz podstawowy jest używany do odwoływania się do rekordów, więc domyślam się, że users.Id jest kluczem podstawowym w tabeli. A indeks jest skanowany w poszukiwaniu poprawnych wartości latitude .
Kwerenda, która nie używa indeksu, nie używa go z dwóch powodów. Po pierwsze, warunki na kolumnach to nierówności. Wyszukiwanie indeksu może używać tylko warunków równości i jednej nierówności. Oznacza to, że indeks może być używany tylko dla latitude w swojej najskuteczniejszej metodzie. Po drugie, dodatkowe kolumny w zapytaniu i tak wymagają przejścia do strony danych.
Innymi słowy, optymalizator w efekcie mówi:„Po co zawracać sobie głowę przechodzeniem do indeksu w celu przeskanowania indeksu, a następnie skanowania stron danych? Zamiast tego mogę po prostu zeskanować strony danych i uzyskać wszystko na raz”.
Twoje następne pytanie to niewątpliwie:„Ale jak przyspieszyć moje zapytanie?” Proponuję zbadać indeksy przestrzenne .
