Vous demandez simplement deux colonnes dans votre requête, donc les index pourraient/devraient y aller :
- DateHeure
- Temps de chargement
Une autre façon d'accélérer votre requête pourrait être de diviser le champ DateTime en deux :date et heure.
De cette façon, db peut regrouper directement sur le champ de date au lieu de calculer DATE(...).
MODIFIÉ :
Si vous préférez utiliser un déclencheur, créez une nouvelle colonne (DATE) et appelez-la newdate , et essayez ceci (je ne peux pas l'essayer maintenant pour voir si c'est correct) :
CREATE TRIGGER upd_check BEFORE INSERT ON SpeedMonitor
FOR EACH ROW
BEGIN
SET NEW.newdate=DATE(NEW.DateTime);
END
ÉDITÉ À NOUVEAU :
Je viens de créer une base de données avec la même table speedmonitor remplie d'environ 900 000 enregistrements.
Ensuite, j'exécute la requête SELECT newdate,AVG(LoadTime) loadtime FROM speedmonitor GROUP BY newdate et cela a pris environ 100s !!
Suppression de l'index sur le champ newdate (et vidage du cache à l'aide de RESET QUERY CACHE et FLUSH TABLES ), la même requête a pris 0,6 s !!!
Juste à titre de comparaison :requête SELECT DATE(DateTime),AVG(LoadTime) loadtime FROM speedmonitor GROUP BY DATE(DateTime) a pris 0,9 s.
Je suppose donc que l'index sur newdate n'est pas bon :supprimez-le.
Je vais maintenant ajouter autant d'enregistrements que possible et tester à nouveau deux requêtes.
MODIFICATION FINALE :
Suppression des index sur les colonnes newdate et DateTime, ayant 8 millions d'enregistrements sur la table speedmonitor, voici les résultats :
- sélectionner et regrouper sur la colonne newdate :7.5s
- sélection et regroupement sur le champ DATE(DateTime) :13,7 s
Je pense que c'est une bonne accélération.
L'exécution de la requête dans l'invite de commande mysql prend du temps.
