Sådan går tingene. Bær over med mig et øjeblik...
Optimizeren vil gerne bruge en INDEX, i dette tilfælde ACTI_DATE_I. Men den ønsker ikke at bruge det, hvis det ville være langsommere.
Plan A:Brug indekset.
- Nå ind i det BTree-strukturerede indeks i slutningen (på grund af DESC)
- Scan baglæns
- For hver række i indekset skal du slå den tilsvarende række op i dataene. Bemærk:Indekset har (ACTIVITY_DATE, ACTIVITY_ID), fordi den PRIMÆR NØGLE er implicit tilføjet til enhver sekundær nøgle. At nå ind i "dataene" ved hjælp af PK'en (ACTIVITY_ID) er et andet BTree-opslag, potentielt tilfældigt. Derfor er det potentielt langsomt. (Men ikke særlig langsom i dit tilfælde.)
- Dette stopper efter LIMIT rækker.
Plan B:Ignorer tabellen
- Scan tabellen, opbyg en tmp-tabel. (Sandsynligvis i hukommelsen.)
- Sorter tmp-tabellen
- Træl LIMIT rækker af.
I dit tilfælde (96 -- 1 % af 10K) er det overraskende, at den valgte tabelscanningen. Normalt er cutoff et sted omkring 10 %-30 % af antallet af rækker i tabellen.
ANALYZE TABLE skal har forårsaget en genberegning af statistikken, hvilket kunne har overbevist det om at gå med den anden plan.
Hvilken version af MySQL bruger du? (Nej, jeg kender ikke til nogen ændringer på dette område.)
En ting du kan prøve:OPTIMIZE TABLE ACTIVITIES; Det vil genopbygge bordet og derved pakke blokkene igen og føre til potentielt forskellige statistikker. Hvis det hjælper, vil jeg gerne vide det -- da jeg normalt siger "Optimer tabel er ubrugelig".