Je vraagt gewoon om twee kolommen in je zoekopdracht, dus indexen kunnen/moeten daar komen:
- DateTime
- LoadTime
Een andere manier om uw zoekopdracht te versnellen, is door het DateTime-veld in tweeën te splitsen:datum en tijd.
Op deze manier kan db direct op het datumveld groeperen in plaats van DATE(...) te berekenen.
BEWERKT:
Als je liever een trigger gebruikt, maak dan een nieuwe kolom (DATE) en noem deze newdate , en probeer hiermee (ik kan het nu niet proberen om te zien of het correct is):
CREATE TRIGGER upd_check BEFORE INSERT ON SpeedMonitor
FOR EACH ROW
BEGIN
SET NEW.newdate=DATE(NEW.DateTime);
END
OPNIEUW BEWERKT:
Ik heb zojuist een db gemaakt met dezelfde tabel speedmonitor gevuld met ongeveer 900.000 records.
Vervolgens voer ik de query SELECT newdate,AVG(LoadTime) loadtime FROM speedmonitor GROUP BY newdate en het duurde ongeveer 100 seconden!!
Verwijderen van index op newdate-veld (en wissen van cache met RESET QUERY CACHE en FLUSH TABLES ), duurde dezelfde query 0,6 s!!!
Alleen ter vergelijking:query SELECT DATE(DateTime),AVG(LoadTime) loadtime FROM speedmonitor GROUP BY DATE(DateTime) nam 0,9 s in beslag.
Dus ik neem aan dat de index op nieuwe datum niet goed is:verwijder hem.
Ik ga nu zoveel records toevoegen als ik kan en twee zoekopdrachten opnieuw testen.
DEFINITIEVE BEWERKING:
Indexen verwijderen op newdate- en DateTime-kolommen met 8mln-records op speedmonitor-tabel, hier zijn resultaten:
- selecteren en groeperen in kolom nieuwe datum:7,5s
- selecteren en groeperen op veld DATE(DateTime):13.7s
Ik denk dat het een goede versnelling is.
Er wordt tijd besteed aan het uitvoeren van de query in de mysql-opdrachtprompt.