Escribiría la consulta así:
SELECT c.time
, SUM(c.counter)
, MAX(p.clustername) AS clustername
FROM cell c
JOIN swap_plan p
ON p.siteid = c.siteid
AND p.clustername = 'Cluster A'
WHERE c.time >= 'day1'
AND c.time <= 'day2'
GROUP
BY c.time
Me aseguraría de tener un índice en cell con time como columna principal.
MySQL puede usar el mismo índice para satisfacer el predicado de rango (en la cláusula WHERE) y para satisfacer el GROUP BY sin una operación de "Uso de clasificación de archivos".
... ON cell (time)
Dependiendo de los tamaños de las columnas, un índice de cobertura podría brindar un rendimiento óptimo. Un índice de cobertura incluye todas las columnas de la tabla a las que se hace referencia en la consulta, por lo que la consulta se puede satisfacer por completo desde las páginas de índice sin buscar páginas en la tabla subyacente.
... ON cell (time, siteid, counter)
Para el índice en swap_plan , tendría un índice con site_id como columna principal e incluyendo el clustername columna, cualquiera de:
... ON swap_plan (clustername, site_id)
o
... ON swap_plan (site_id, clustername)
Parece probable que haya una restricción ÚNICA en la combinación de esas dos columnas, es decir, los valores de site_id será distinto para un clustername dado . (Si ese no es el caso, y el mismo (site_id,clustername) la tupla aparece varias veces, existe la posibilidad de un total agregado de counter para ser inflado.
Estaría buscando EXPLAIN salida para mostrar una búsqueda 'ref' a swap_plan tabla del valor de c.siteid y const (literal 'Cluster A') valor para clustername.
Con tablas de 31 filas y 368 filas, no vamos a ver una diferencia significativa en el rendimiento (tiempo transcurrido) entre un plan de ejecución óptimo y un plan de ejecución horrible.
Cuando cualquiera de las tablas escala hasta millones de filas, es cuando las diferencias se hacen evidentes. La elección del plan de ejecución de los optimizadores está influenciada por las estadísticas (tamaño, número de filas, cardinalidad de columna) de cada tabla, por lo que el plan de ejecución podría cambiar con un aumento en el tamaño de las tablas.
