Dotaz bych napsal takto:
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
Určitě bych měl index na cell s time jako vedoucí sloupec.
MySQL může použít stejný index ke splnění predikátu rozsahu (v klauzuli WHERE) a ke splnění GROUP BY bez operace "Using filesort".
... ON cell (time)
V závislosti na velikosti sloupců může mít index pokrytí optimální výkon. Pokrývající index zahrnuje všechny sloupce z tabulky, na které se odkazuje v dotazu, takže dotaz lze uspokojit výhradně ze stránek indexu bez vyhledávání stránek v podkladové tabulce.
... ON cell (time, siteid, counter)
Pro index na swap_plan , měl bych index s site_id jako úvodní sloupec a včetně clustername jeden z:
... ON swap_plan (clustername, site_id)
nebo
... ON swap_plan (site_id, clustername)
Zdá se pravděpodobné, že bude existovat UNIKÁTNÍ omezení pro kombinaci těchto dvou sloupců, tj. hodnoty site_id bude odlišné pro daný clustername . (Pokud tomu tak není, a stejné (site_id,clustername) n-tice se objeví vícekrát, existuje potenciál pro celkový součet counter být nafouknutý.
Hledal bych EXPLAIN výstup zobrazí 'ref' vyhledávání swap_plan tabulky z hodnoty c.siteid a hodnotu const (doslova 'Cluster A') pro název clusteru.
S tabulkami o velikosti 31 řádků a 368 řádků neuvidíme významný rozdíl ve výkonu (uplynulý čas) mezi optimálním plánem provádění a hrozným plánem provádění.
Když se některá z tabulek zvětší na miliony řádků, rozdíly se projeví. Volba plánu provádění optimalizátorů je ovlivněna statistikami (velikost, počet řádků, mohutnost sloupců) každé tabulky, takže plán provádění se může se zvětšením velikosti tabulek měnit.