Así es como van las cosas. Ten paciencia conmigo un minuto...
Al Optimizador le gustaría usar un ÍNDICE, en este caso ACTI_DATE_I. Pero no quiere usarlo si eso sería más lento.
Plan A:usa el índice.
- Acceda al índice estructurado en BTree al final (debido a DESC)
- Escanear hacia atrás
- Para cada fila del índice, busque la fila correspondiente en los datos. Nota:El índice tiene (ACTIVITY_DATE, ACTIVITY_ID) porque PRIMARY KEY se agrega implícitamente a cualquier clave secundaria. Alcanzar los "datos" usando el PK (ACTIVITY_ID) es otra búsqueda de BTree, potencialmente aleatoria. Por lo tanto, es potencialmente lento. (Pero no muy lento en su caso).
- Esto se detiene después de LIMIT filas.
Plan B:Ignorar la mesa
- Escanea la tabla, creando una tabla tmp. (Es probable que esté en la memoria.)
- Ordenar la tabla tmp
- Elimine LIMIT filas.
En su caso (96 -- 1% de 10K) es sorprendente que haya elegido el escaneo de la tabla. Normalmente, el límite está entre el 10 % y el 30 % del número de filas de la tabla.
ANALYZE TABLE debería han provocado un recálculo de las estadísticas, lo que podría lo han convencido para ir con el otro Plan.
¿Qué versión de MySQL estás usando? (No, no conozco ningún cambio en esta área).
Una cosa que podría intentar:OPTIMIZE TABLE ACTIVITIES; Eso reconstruirá la tabla, volviendo a empaquetar los bloques y conduciendo a potencialmente estadísticas diferentes. Si eso ayuda, me gustaría saberlo, ya que normalmente digo "Optimizar la tabla es inútil".
