Ve svém dotazu požadujete pouze dva sloupce, takže indexy by tam mohly/měly být:
- Datum a čas
- Doba načítání
Dalším způsobem, jak urychlit dotaz, by mohlo být rozdělení pole DateTime na dvě části:datum a čas.
Tímto způsobem může db seskupovat přímo do pole data namísto výpočtu DATE(...).
UPRAVENO:
Pokud dáváte přednost použití spouštěče, vytvořte nový sloupec (DATE) a nazvěte jej newdate , a zkuste to s tímto (teď to nemohu vyzkoušet, abych zjistil, zda je to správné):
CREATE TRIGGER upd_check BEFORE INSERT ON SpeedMonitor
FOR EACH ROW
BEGIN
SET NEW.newdate=DATE(NEW.DateTime);
END
ZNOVU UPRAVENO:
Právě jsem vytvořil db se stejnou tabulkou speedmonitor naplněnou asi 900 000 záznamy.
Poté spustím dotaz SELECT newdate,AVG(LoadTime) loadtime FROM speedmonitor GROUP BY newdate a trvalo to asi 100 s!!
Odstranění indexu v poli newdate (a vymazání mezipaměti pomocí RESET QUERY CACHE
a FLUSH TABLES
), stejný dotaz trval 0,6 s!!!
Jen pro srovnání:dotaz SELECT DATE(DateTime),AVG(LoadTime) loadtime FROM speedmonitor GROUP BY DATE(DateTime)
trvalo 0,9 s.
Předpokládám tedy, že index na newdate není dobrý:odeberte jej.
Přidám co nejvíce záznamů a znovu otestuji dva dotazy.
KONEČNÁ ÚPRAVA:
Odstranění indexů ve sloupcích newdate a DateTime, které mají 8 milionů záznamů v tabulce speedmonitoru jsou výsledky:
- výběr a seskupení podle sloupce nové datum:7,5 s
- výběr a seskupení v poli DATE(DateTime):13,7 s
Myslím, že je to dobré zrychlení.
Provedení dotazu v příkazovém řádku mysql trvá.