Det är så det går. Håll ut med mig en minut...
Optimizern skulle vilja använda ett INDEX, i det här fallet ACTI_DATE_I. Men den vill inte använda den om det skulle gå långsammare.
Plan A:Använd indexet.
- Nå in i det BTree-strukturerade indexet i slutet (på grund av DESC)
- Skanna bakåt
- För varje rad i indexet, slå upp motsvarande rad i data. Obs:Indexet har (ACTIVITY_DATE, ACTIVITY_ID) eftersom den PRIMÄRKEY är implicit fogad till en sekundär nyckel. Att nå in i "data" med hjälp av PK (ACTIVITY_ID) är en annan BTree-uppslagning, potentiellt slumpmässig. Därför är det potentiellt långsamt. (Men inte särskilt långsam i ditt fall.)
- Detta slutar efter LIMIT rader.
Plan B:Ignorera tabellen
- Skanna tabellen och bygg en tmp-tabell. (Har sannolikt i minnet.)
- Sortera tmp-tabellen
- Ta bort LIMIT rader.
I ditt fall (96 -- 1% av 10K) är det förvånande att den valde tabellskanningen. Normalt är cutoff någonstans runt 10%-30% av antalet rader i tabellen.
ANALYZE TABLE bör har orsakat en omräkning av statistiken, vilket kan har övertygat den att gå med den andra planen.
Vilken version av MySQL använder du? (Nej, jag känner inte till några förändringar på detta område.)
En sak du kan prova:OPTIMIZE TABLE ACTIVITIES; Det kommer att bygga om bordet och därigenom packa om blocken och leda till potentiellt olika statistik. Om det hjälper, skulle jag vilja veta det -- eftersom jag normalt säger "Optimera tabell är värdelös".