Jag skulle skriva frågan så här:
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
Jag skulle vara säker på att ha ett index på cell med time som den ledande kolumnen.
MySQL kan använda samma index för att uppfylla intervallpredikatet (i WHERE-satsen), och för att uppfylla GROUP BY utan en "Using filesort"-operation.
... ON cell (time)
Beroende på storleken på kolumnerna kan ett täckande index ge optimal prestanda. Ett täckande index inkluderar alla kolumner från tabellen som refereras till i frågan, så frågan kan tillfredsställas helt från indexsidor utan uppslag till sidor i den underliggande tabellen.
... ON cell (time, siteid, counter)
För indexet på swap_plan , jag skulle ha ett index med site_id som den inledande kolumnen, och inklusive clustername kolumn, någon av:
... ON swap_plan (clustername, site_id)
eller
... ON swap_plan (site_id, clustername)
Det verkar troligt att det kommer att finnas en UNIK begränsning för kombinationen av dessa två kolumner, dvs värdena för site_id kommer att vara distinkt för ett givet clustername . (Om så inte är fallet, och samma (site_id,clustername) tupel visas flera gånger, det finns potential för sammanlagd summa av counter att blåsas upp.
Jag skulle leta efter EXPLAIN output för att visa en "ref"-uppslagning till swap_plan tabell från värdet för c.siteid och const (bokstavligen 'Kluster A') värde för klusternamn.
Med tabeller med 31 rader och 368 rader kommer vi inte att se någon signifikant skillnad i prestanda (förfluten tid) mellan en optimal exekveringsplan och en hemsk exekveringsplan.
När någon av tabellerna skalas upp till miljontals rader, är det då skillnaderna blir uppenbara. Optimerarens val av exekveringsplan påverkas av statistik (storlek, antal rader, kolumnkardinalitet) för varje tabell, så exekveringsplanen kan ändras med en ökning av tabellstorlekar.