Това е малко трудно за обяснение.
Заявката, която използва индекса, го използва, защото индексът е "покриващ" индекс. Тоест всички колони в индекса са в заявката. Единствената част от индекса, която наистина се използва ефективно, е условието за latitude .
Обикновено покриващият индекс ще има само колоните, споменати в заявката. Първичният ключ обаче се използва за препратка към записите, така че предполагам, че users.Id е първичният ключ на таблицата. И индексът се сканира за валидни стойности на latitude .
Заявката, която не използва индекса, не го използва по две причини. Първо, условията на колоните са неравенства. Търсенето на индекс може да използва само условия за равенство и едно неравенство. Това означава, че индексът може да се използва само за latitude в най-ефективния си метод. Второ, допълнителните колони в заявката така или иначе изискват отиване на страницата с данни.
С други думи, оптимизаторът всъщност казва:„Защо да си правя труда да отивам в индекса, за да сканирам индекса и след това да сканирам страниците с данни? Вместо това мога просто да сканирам страниците с данни и да получа всичко наведнъж.“
Следващият ви въпрос несъмнено е:"Но как да направя заявката си по-бърза?" Моето предложение би било да се изследват пространствени индекси .
