Cuando añadir un índice ralentiza
La tabla de cifras diarias tiene una clave: el contador y la fecha juntos. Cinco lugares del código le hacen otra pregunta — no «este contador a lo largo del tiempo», sino «todos los contadores en estos días». La galería de la portada, la clasificación, el mapa del sitio, un gráfico de 90 días y las cifras de estado. Sin un índice en la columna de fecha, cada una de ellas lee las 114.113 filas.
Ese índice hace la galería diez veces más rápida. No se añadió. Esta es la medición que lo decidió.
Una consulta se volvió mucho más rápida
La galería pide los contadores que han tenido visitas hoy. Sin índice en la fecha recorre la tabla entera; con índice busca una sola fecha y lee 443 filas. De 61,5 milisegundos se pasó a 6,1. No es un resultado sutil, y si hubiera sido lo único medido, el índice estaría ahora en la base de datos.
Dos consultas se volvieron más lentas
El mapa del sitio pide catorce días y se volvió un 19 % más lento. Las cifras de estado piden un año y se volvieron un 10 % más lentas. En ambos casos el planificador cambió de la clave primaria al índice nuevo y eligió peor.
Esta es la parte que conviene entender, porque no es un fallo del planificador. Leer un rango a través de un índice secundario significa encontrar las filas coincidentes en el índice y luego traer cada una de la tabla. Para una rebanada estrecha es una ganga. Para catorce días de trece meses siguen siendo muchas filas traídas de una en una, y un recorrido directo de la tabla — leída en orden físico, que es lo que les gusta a discos y cachés — lo gana. El planificador no lo sabe. Ve un rango y un índice y lo toma.
No se puede decir «usa este índice solo para la galería». Un índice está disponible para toda consulta que toque esa columna, y el planificador lo usará donde sus estimaciones digan. Añadir uno es un cambio en todas las consultas de esa tabla, no en la que se tenía en mente.
En conjunto: nada
Sumando las cinco, 555 milisegundos se convirtieron en 524. Una mejora de 1,1×, que en una Raspberry Pi que además sirve estas páginas desde una caché no vale un cambio de esquema.
El gráfico de 90 días parece haber mejorado un 9 %. No se cuenta, y merece la pena decir por qué. Cada consulta se midió tres veces: sin el índice, con él, y otra vez sin él. Si la segunda pasada sin índice no cae cerca de la primera, la diferencia fue la máquina, no el cambio. En el gráfico de 90 días las dos pasadas sin índice diferían un 13,8 % — más que el efecto que se afirmaría. Así que esa fila no mide nada, y como nada se informa.
Cómo se midió, y por qué eso importa
No sobre la tabla en marcha. El script hace una copia, trabaja sobre la copia y la borra al final. Añadir un índice a una tabla de producción para ver qué pasa es algo que solo se puede hacer una vez por sorpresa.
Las consultas son las reales, sacadas del código, incluida la unión con la tabla de contadores. Una versión anterior de esta prueba usó un sustituto simplificado y dio una respuesta mucho más emocionante: veinte veces más rápido. Esa consulta simplificada no la ejecuta nada.
Qué número habría salido
De haberlo medido de la manera corriente — coger la consulta que parece lenta y cronometrarla antes y después — la respuesta habría sido «diez veces más rápido, adelante». El índice habría entrado, la galería habría acelerado, el mapa del sitio y la página de estado se habrían ralentizado, y nadie habría conectado ambas cosas, porque nadie las estaba mirando.
Esa es la forma general del asunto. Un cambio en infraestructura compartida no se puede evaluar sobre el caso que lo motivó. La pregunta no es «¿ayuda esto a lo que estoy mirando?» sino «¿qué más toca esto y qué le pasa?».
Hay una versión que podría funcionar: un índice que lleve ambas columnas, la fecha primero, de modo que la galería se pueda responder solo desde el índice, sin volver a la tabla. Quizá tampoco tiente al planificador en los rangos amplios. Eso no está medido, así que no es una recomendación — es lo siguiente que irá a la copia.