Zapytałbym tak:
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
Chciałbym mieć indeks na cell z time jako wiodąca kolumna.
MySQL może użyć tego samego indeksu, aby spełnić predykat zakresu (w klauzuli WHERE) i spełnić warunek GROUP BY bez operacji „Using filesort”.
... ON cell (time)
W zależności od rozmiarów kolumn indeks pokrycia może zapewnić optymalną wydajność. Indeks pokrywający zawiera wszystkie kolumny z tabeli, do których odwołuje się zapytanie, więc zapytanie może być w całości spełnione ze stron indeksu bez wyszukiwania stron w tabeli bazowej.
... ON cell (time, siteid, counter)
Indeks na swap_plan , miałbym indeks z site_id jako wiodącą kolumnę, z uwzględnieniem clustername kolumna, dowolna z:
... ON swap_plan (clustername, site_id)
lub
... ON swap_plan (site_id, clustername)
Wygląda na to, że na połączeniu tych dwóch kolumn, tj. wartościach site_id, pojawi się ograniczenie typu UNIQUE będzie odrębna dla danego clustername . (Jeśli tak nie jest, i ten sam (site_id,clustername) krotka pojawia się wiele razy, istnieje możliwość zagregowania sumy counter być napompowanym.
szukałbym EXPLAIN wyjście, aby pokazać odnośnik 'ref' do swap_plan tabela z wartości c.siteid i wartość const (dosłownie „Cluster A”) dla nazwy klastra.
W przypadku tabel o rozmiarze 31 i 368 wierszy nie zobaczymy znaczącej różnicy w wydajności (upływający czas) między optymalnym planem wykonania a okropnym planem wykonania.
Kiedy któraś z tabel skaluje się do milionów wierszy, wtedy różnice staną się widoczne. Na wybór planu wykonania optymalizatora mają wpływ statystyki (rozmiar, liczba wierszy, liczność kolumn) każdej tabeli, więc plan wykonania może się zmieniać wraz ze wzrostem rozmiarów tabeli.
