Du ville nok være bedre stillet ved at lade MySql bestemme forespørgselsplanen. Der er en god chance for, at en indeksscanning ville være mindre effektiv end en fuld tabelscanning.
Der er to datastrukturer på disken til denne tabel
- Selve tabellen; og
- Den primære nøgle B-Tree indeks.
Når du kører en forespørgsel, har optimeringsværktøjet to muligheder for, hvordan du får adgang til dataene:
SELECT * FROM userapplication WHERE application_id > 1025;
Brug af indekset
- Scan B-Tree-indekset for at finde adressen på alle rækker, hvor
application_id > 1025 - Læs de relevante sider i tabellen for at få data for disse rækker.
Bruger ikke indekset
Scan hele tabellen, og vælg de relevante poster.
Valg af den bedste strategi
Forespørgselsoptimeringsopgaven er at vælge den mest effektive strategi til at få de data, du ønsker. Hvis der er mange rækker med et application_id > 1025 så kan det faktisk være mindre effektivt at bruge indekset. For eksempel hvis 90 % af posterne har et application_id > 1025 så skulle forespørgselsoptimeringsværktøjet scanne omkring 90 % af bladknuderne i b-træets indeks og derefter læse mindst 90 % af tabellen også for at få de faktiske data; dette ville involvere læsning af flere data fra disken end blot at scanne tabellen.