Mysql
 sql >> Database >  >> RDS >> Mysql

Indicizzazione corretta per Join-Where-Group Selezionando le query evitando l'utilizzo temporaneo; Utilizzo di filesort

Scriverei la query in questo modo:

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

Sarei sicuro di avere un indice su cell con time come colonna principale.

MySQL può utilizzare lo stesso indice per soddisfare il predicato range (nella clausola WHERE) e per soddisfare GROUP BY senza un'operazione "Using filesort".

... ON cell (time)

A seconda delle dimensioni delle colonne, un indice di copertura potrebbe fornire prestazioni ottimali. Un indice di copertura include tutte le colonne della tabella a cui si fa riferimento nella query, quindi la query può essere soddisfatta interamente dalle pagine dell'indice senza cercare le pagine nella tabella sottostante.

... ON cell (time, siteid, counter)

Per l'indice su swap_plan , avrei un indice con site_id come colonna iniziale e include il clustername colonna, una delle seguenti:

... ON swap_plan (clustername, site_id)

o

... ON swap_plan (site_id, clustername)

È probabile che ci sarà un vincolo UNICO sulla combinazione di queste due colonne, ovvero i valori di site_id sarà distinto per un dato clustername . (In caso contrario, e lo stesso (site_id,clustername) tupla appare più volte, c'è il potenziale per il totale aggregato di counter da gonfiare.

Cercherei il EXPLAIN output per mostrare una ricerca 'ref' su swap_plan tabella dal valore di c.siteid e valore const (letterale 'Cluster A') per clustername.

Con tabelle di dimensioni 31 righe e 368 righe, non vedremo una differenza significativa nelle prestazioni (tempo trascorso) tra un piano di esecuzione ottimale e un piano di esecuzione orribile.

Quando una delle tabelle viene ridimensionata fino a milioni di righe, è allora che le differenze diventeranno evidenti. La scelta del piano di esecuzione degli ottimizzatori è influenzata dalle statistiche (dimensione, numero di righe, cardinalità di colonna) di ciascuna tabella, quindi il piano di esecuzione potrebbe cambiare con un aumento delle dimensioni delle tabelle.