Los índices no necesariamente mejoran el rendimiento. Para comprender mejor lo que está sucediendo, ayudaría si incluyera el explain para las diferentes consultas.
Mi mejor suposición sería que tiene un índice en id_state o incluso id_state, id_mp que se puede usar para satisfacer el where cláusula. Si es así, la primera consulta sin order by usaría este índice. Debería ser bastante rápido. Incluso sin un índice, esto requiere un escaneo secuencial de las páginas en los orders mesa, que aún puede ser bastante rápido.
Luego, cuando agrega el índice en creation_date , MySQL decide usar ese índice en su lugar para order by . Esto requiere leer cada fila en el índice, luego obtener la página de datos correspondiente para verificar el where condiciones y devolver las columnas (si hay una coincidencia). Esta lectura es altamente ineficiente, porque no está en el orden de las "páginas", sino más bien como lo especifica el índice. Las lecturas aleatorias pueden ser bastante ineficientes.
Peor aún, aunque tenga un limit , todavía tienes que leer el todo tabla porque se necesita todo el conjunto de resultados. Aunque ha guardado una ordenación en 38 registros, ha creado una consulta enormemente ineficiente.
Por cierto, esta situación empeora significativamente si los orders la tabla no cabe en la memoria disponible. Entonces tiene una condición llamada "thrashing", donde cada nuevo registro tiende a generar una nueva lectura de E/S. Entonces, si una página tiene 100 registros, es posible que la página deba leerse 100 veces.
Puede hacer que todas estas consultas se ejecuten más rápido si tiene un índice en orders(id_state, id_mp, creation_date) . El where utilizará las dos primeras columnas y el order by usará el último.
