Jeg ville skrive forespørgslen sådan her:
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
Jeg vil være sikker på at have et indeks på cell med time som den ledende kolonne.
MySQL kan bruge det samme indeks til at tilfredsstille områdeprædikatet (i WHERE-sætningen) og til at opfylde GROUP BY uden en "Using filesort"-operation.
... ON cell (time)
Afhængigt af søjlernes størrelse kan et dækkende indeks give optimal ydeevne. Et dækkende indeks inkluderer alle de kolonner fra tabellen, der refereres til i forespørgslen, så forespørgslen kan opfyldes helt fra indekssider uden opslag til sider i den underliggende tabel.
... ON cell (time, siteid, counter)
Til indekset på swap_plan , ville jeg have et indeks med site_id som den ledende kolonne, og inklusive clustername kolonne, enten af:
... ON swap_plan (clustername, site_id)
eller
... ON swap_plan (site_id, clustername)
Det ser sandsynligt ud til, at der vil være en UNIK begrænsning på kombinationen af disse to kolonner, dvs. værdierne for site_id vil være distinkt for et givet clustername . (Hvis det ikke er tilfældet, og det samme (site_id,clustername) tuple vises flere gange, er der potentiale for samlet counter at blive oppustet.
Jeg leder efter EXPLAIN output for at vise et 'ref'-opslag til swap_plan tabel fra værdien af c.siteid og const (bogstaveligt 'Klynge A') værdi for klyngenavn.
Med tabeller med en størrelse på 31 rækker og 368 rækker, vil vi ikke se en væsentlig forskel i ydeevne (forløbet tid) mellem en optimal eksekveringsplan og en forfærdelig eksekveringsplan.
Når en af tabellerne skaleres op til millioner af rækker, er det, når forskellene bliver tydelige. Optimizerens valg af eksekveringsplan er påvirket af statistik (størrelse, antal rækker, kolonnekardinalitet) for hver tabel, så udførelsesplanen kan ændre sig med en stigning i tabelstørrelser.