Ik zou de vraag als volgt schrijven:
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
Ik zou zeker een index hebben op cell met time als de leidende kolom.
MySQL kan dezelfde index gebruiken om te voldoen aan het bereikpredikaat (in de WHERE-component) en om te voldoen aan de GROUP BY zonder een "Using filesort"-bewerking.
... ON cell (time)
Afhankelijk van de afmetingen van de kolommen kan een dekkingsindex optimale prestaties geven. Een dekkende index omvat alle kolommen uit de tabel waarnaar in de zoekopdracht wordt verwezen, zodat de zoekopdracht volledig kan worden vervuld vanaf indexpagina's zonder dat er naar pagina's in de onderliggende tabel hoeft te worden gezocht.
... ON cell (time, siteid, counter)
Voor de index op swap_plan , ik zou een index hebben met site_id als de leidende kolom, en inclusief de clustername kolom, een van de volgende:
... ON swap_plan (clustername, site_id)
of
... ON swap_plan (site_id, clustername)
Het lijkt waarschijnlijk dat er een UNIEKE beperking zal zijn voor de combinatie van die twee kolommen, d.w.z. de waarden van site_id zal verschillend zijn voor een gegeven clustername . (Als dat niet het geval is, en hetzelfde (site_id,clustername) tuple verschijnt meerdere keren, er is potentieel voor een totaal van counter op te blazen.
Ik zou op zoek zijn naar de EXPLAIN output om een 'ref' lookup te tonen naar swap_plan tabel uit de waarde van c.siteid en const (letterlijk 'Cluster A') waarde voor clusternaam.
Met tabellen met een grootte van 31 rijen en 368 rijen, zullen we geen significant verschil in prestaties (verstreken tijd) zien tussen een optimaal uitvoeringsplan en een vreselijk uitvoeringsplan.
Wanneer een van de tabellen wordt opgeschaald naar miljoenen rijen, worden de verschillen duidelijk. De keuze van de optimalisatie voor het uitvoeringsplan wordt beïnvloed door statistieken (grootte, aantal rijen, kolomkardinaliteit) van elke tabel, dus het uitvoeringsplan kan veranderen als de tabel groter wordt.