C'est ainsi que les choses se passent. Patientez avec moi une minute...
L'optimiseur souhaite utiliser un INDEX, dans ce cas ACTI_DATE_I. Mais il ne veut pas l'utiliser si cela serait plus lent.
Plan A :Utilisez l'index.
- Atteindre l'index structuré en arbre à la fin (à cause de DESC)
- Balayer vers l'arrière
- Pour chaque ligne de l'index, recherchez la ligne correspondante dans les données. Remarque :L'index a (ACTIVITY_DATE, ACTIVITY_ID) car la PRIMARY KEY est implicitement ajoutée à toute clé secondaire. Accéder aux "données" en utilisant le PK (ACTIVITY_ID) est une autre recherche BTree, potentiellement aléatoire. Il est donc potentiellement lent. (Mais pas très lent dans votre cas.)
- Cela s'arrête après LIMIT lignes.
Plan B :Ignorer le tableau
- Scannez la table, construisant une table tmp. (Probablement en mémoire.)
- Trier la table tmp
- Décollez LIMIT lignes.
Dans votre cas (96 -- 1% de 10K), il est surprenant qu'il ait choisi le scan de table. Normalement, le seuil se situe entre 10 % et 30 % du nombre de lignes du tableau.
ANALYZE TABLE devrait ont provoqué un recalcul des statistiques, ce qui pourrait l'ont convaincu d'aller avec l'autre Plan.
Quelle version de MySQL utilisez-vous ? (Non, je ne suis au courant d'aucun changement dans ce domaine.)
Une chose que vous pourriez essayer :OPTIMIZE TABLE ACTIVITIES; Cela reconstruira la table, remballant ainsi les blocs et conduisant à potentiellement différentes statistiques. Si cela aide, j'aimerais le savoir - puisque je dis normalement "Optimiser la table est inutile".
