È così che vanno le cose. Abbi pazienza un minuto...
L'Ottimizzatore vorrebbe utilizzare un INDEX, in questo caso ACTI_DATE_I. Ma non vuole usarlo se sarebbe più lento.
Piano A:usa l'indice.
- Raggiungi l'indice strutturato BTree alla fine (grazie al DESC)
- Scansione indietro
- Per ogni riga nell'indice, cerca la riga corrispondente nei dati. Nota:l'indice ha (ACTIVITY_DATE, ACTIVITY_ID) perché la PRIMARY KEY è implicitamente aggiunta a qualsiasi chiave secondaria. Per accedere ai "dati" utilizzando il PK (ACTIVITY_ID) è un'altra ricerca Btree, potenzialmente casuale. Quindi, è potenzialmente lento. (Ma non molto lento nel tuo caso.)
- Ciò si interrompe dopo LIMIT righe.
Piano B:ignora la tabella
- Scansiona la tabella, costruendo una tabella tmp. (Probabilmente in memoria.)
- Ordina la tabella tmp
- Stacca le righe LIMIT.
Nel tuo caso (96 - 1% di 10K) è sorprendente che abbia scelto la scansione della tabella. Normalmente, il limite è intorno al 10%-30% del numero di righe nella tabella.
ANALYZE TABLE dovrebbe hanno causato un ricalcolo delle statistiche, che potrebbe l'hanno convinto ad andare con l'altro Piano.
Che versione di MySQL stai usando? (No, non sono a conoscenza di modifiche in quest'area.)
Una cosa che potresti provare:OPTIMIZE TABLE ACTIVITIES; Ciò ricostruirà la tabella, reimballando così i blocchi e portando a potenzialmente statistiche diverse. Se questo aiuta, vorrei saperlo, dal momento che normalmente dico "Ottimizza la tabella è inutile".
