Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

Indexação correta por Join-Where-Group Por selecionar consultas evitando Usar temporário; Usando a classificação de arquivos


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.