Consulte Cómo usa MySQL los índices .
También valide si MySQL aún realiza un análisis completo de la tabla después de agregar unas 2000 filas adicionales a su user_metrics mesa. En tablas pequeñas, el acceso por índice es en realidad más costoso (en cuanto a E/S) que un escaneo de tabla, y el optimizador de MySQL podría tener esto en cuenta.
Al contrario de mi publicación anterior , resulta que MySQL también utiliza un optimizador basado en costos
, lo cual es una muy buena noticia, es decir, siempre que ejecute su ANALYZE al menos una vez cuando crea que el volumen de datos en su base de datos es representativo del futuro uso diario.
Cuando se trata de optimizadores basados en costos (Oracle, Postgres, etc.), debe asegurarse de ejecutar periódicamente ANALYZE
en sus diversas mesas a medida que su tamaño aumenta en más de un 10-15%. (Postgres hará esto automáticamente por usted, de forma predeterminada, mientras que otros RDBMS dejarán esta responsabilidad a un DBA, es decir, a usted). A través del análisis estadístico, ANALYZE ayudará al optimizador a tener una mejor idea de la cantidad de E/S (y otros recursos asociados, como la CPU, necesarios, por ejemplo, para la clasificación) que estarán involucrados al elegir entre varios planes de ejecución candidatos. Error al ejecutar ANALYZE puede dar lugar a decisiones de planificación muy malas, a veces desastrosas (por ejemplo, consultas de milisegundos que tardan, a veces, horas debido a bucles anidados defectuosos en JOIN s.)
Si el rendimiento sigue siendo insatisfactorio después de ejecutar ANALYZE , normalmente podrá solucionar el problema utilizando sugerencias, p. FORCE INDEX , mientras que en otros casos es posible que haya tropezado con un error de MySQL (por ejemplo, este uno anterior , que podría haberte mordido si hubieras usado el nested_set de Rails ).
Ahora, ya que estás en una aplicación de Rails , será engorroso (y anulará el propósito de ActiveRecord ) para emitir sus consultas personalizadas con sugerencias en lugar de continuar usando el ActiveRecord -generados.
Ya había mencionado que en nuestra aplicación Rails todas SELECT las consultas cayeron por debajo de los 100 ms después de cambiar a Postgres, mientras que algunas de las uniones complejas generadas por ActiveRecord Ocasionalmente, tomaría hasta 15 segundos o más con MySQL 5.1 debido a los bucles anidados con escaneos de tablas internas, incluso cuando los índices estaban disponibles. Ningún optimizador es perfecto, y debe conocer las opciones. Otros posibles problemas de rendimiento a tener en cuenta, además de la optimización del plan de consulta, son los bloqueos. Sin embargo, esto está fuera del alcance de su problema.
