Zo gaan de dingen. Heb even geduld met me...
De Optimizer wil graag een INDEX gebruiken, in dit geval ACTI_DATE_I. Maar het wil het niet gebruiken als dat langzamer zou zijn.
Plan A:gebruik de index.
- Reik aan het einde naar de BTree-gestructureerde index (vanwege DESC)
- Scan achteruit
- Zoek voor elke rij in de index de bijbehorende rij op in de gegevens. Opmerking:de index heeft (ACTIVITY_DATE, ACTIVITY_ID) omdat de PRIMARY KEY impliciet wordt toegevoegd aan een secundaire sleutel. Om in de "gegevens" te komen met behulp van de PK (ACTIVITY_ID) is een andere Btree-zoekopdracht, mogelijk willekeurig. Daarom is het potentieel traag. (Maar in jouw geval niet erg traag.)
- Dit stopt na LIMIT rijen.
Plan B:negeer de tafel
- Scan de tabel, bouw een tmp-tabel. (Waarschijnlijk in het geheugen.)
- Sorteer de tmp-tabel
- LIMIT rijen verwijderen.
In jouw geval (96 -- 1% van 10K) is het verrassend dat het de tafelscan heeft gekozen. Normaal gesproken ligt de grens ergens rond de 10%-30% van het aantal rijen in de tabel.
ANALYZE TABLE moeten hebben een herberekening van de statistieken veroorzaakt, wat zou hebben overtuigd dat het bij het andere Plan past.
Welke versie van MySQL gebruik je? (Nee, ik ken geen wijzigingen op dit gebied.)
Eén ding dat je zou kunnen proberen:OPTIMIZE TABLE ACTIVITIES; Dat zal de tabel opnieuw opbouwen, waardoor de blokken opnieuw worden verpakt en leiden tot mogelijk verschillende statistieken. Als dat helpt, zou ik het graag willen weten -- aangezien ik normaal gesproken zeg "Tabel optimaliseren is nutteloos".