Eu escreveria a consulta assim:
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
Eu teria certeza de ter um índice na
cell
com time
como coluna principal. O MySQL pode usar o mesmo índice para satisfazer o predicado range (na cláusula WHERE), e para satisfazer o GROUP BY sem uma operação "Using filesort".
... ON cell (time)
Dependendo dos tamanhos das colunas, um índice de cobertura pode fornecer um desempenho ideal. Um índice de cobertura inclui todas as colunas da tabela que são referenciadas na consulta, para que a consulta possa ser atendida inteiramente a partir de páginas de índice sem pesquisa de páginas na tabela subjacente.
... ON cell (time, siteid, counter)
Para o índice em
swap_plan
, eu teria um índice com site_id
como a coluna inicial e incluindo o clustername
coluna, qualquer um de:... ON swap_plan (clustername, site_id)
ou
... ON swap_plan (site_id, clustername)
Parece provável que haverá uma restrição ÚNICA na combinação dessas duas colunas, ou seja, os valores de
site_id
será distinto para um determinado clustername
. (Se esse não for o caso, e o mesmo (site_id,clustername)
tupla aparece várias vezes, há potencial para total agregado de counter
ser inflado. Eu estaria procurando pelo
EXPLAIN
saída para mostrar uma pesquisa 'ref' para swap_plan
tabela do valor de c.siteid
e valor const (literal 'Cluster A') para clustername. Com tabelas dimensionadas em 31 linhas e 368 linhas, não veremos uma diferença significativa no desempenho (tempo decorrido) entre um plano de execução ideal e um plano de execução horrível.
Quando uma das tabelas é dimensionada para milhões de linhas, é quando as diferenças se tornam aparentes. A escolha do plano de execução do otimizador é influenciada pelas estatísticas (tamanho, número de linhas, cardinalidade da coluna) de cada tabela, de modo que o plano de execução pode mudar com o aumento do tamanho das tabelas.