Du beder bare om to kolonner i din forespørgsel, så indekser kunne/bør gå der:
- DatoTid
- LoadTime
En anden måde at fremskynde din forespørgsel på kunne være at dele DateTime-feltet i to:dato og klokkeslæt.
På denne måde kan db gruppere direkte på datofeltet i stedet for at beregne DATO(...).
REDIGERET:
Hvis du foretrækker at bruge en trigger, skal du oprette en ny kolonne (DATE) og kalde den newdate , og prøv med dette (jeg kan ikke prøve det nu for at se, om det er korrekt):
CREATE TRIGGER upd_check BEFORE INSERT ON SpeedMonitor
FOR EACH ROW
BEGIN
SET NEW.newdate=DATE(NEW.DateTime);
END
REDIGERET IGEN:
Jeg har lige oprettet en db med den samme tabel speedmonitor fyldt med omkring 900.000 poster.
Så kører jeg forespørgslen SELECT newdate,AVG(LoadTime) loadtime FRA speedmonitor GROUP BY newdate og det tog omkring 100'er!!
Fjerner indeks på newdate-feltet (og tømmer cache ved hjælp af NULSTIL FORESPØRGSCACHE
og STYL TABELLER
), tog den samme forespørgsel 0,6s!!!
Bare til sammenligning:forespørgsel VÆLG DATO(DatoTid),AVG(LoadTime) indlæsningstid FRA speedmonitor GRUPPER EFTER DATO(DatoTid)
tog 0,9 s.
Så jeg formoder, at indekset på newdate ikke er godt:fjern det.
Jeg vil tilføje så mange poster, som jeg kan nu og teste to forespørgsler igen.
ENDELIG REDIGERING:
Fjerner indekser på newdate- og DateTime-kolonner med 8 mio. poster på speedmonitor-tabellen, her er resultaterne:
- valg og gruppering på newdate-kolonne:7,5s
- valg og gruppering i feltet DATE(DateTime):13,7 sek.
Jeg synes, det er en god fremskyndelse.
Det tager tid at udføre forespørgslen i mysql-kommandoprompten.