Petite remarque sur les perfs à certains endroits, pour l'interface de correction.
Je pense d'ailleurs qu'il y a le même soucis sur l'interface de visualisation (en indiquant l'ID de mon device compteur en bas du tableau, j'ai eu le même soucis).
J'ai changé de compteur (welcome linky), et je pensais corriger les quelques données foireuses via l'interface.
Hors, quand je saisie une date de début dans la recherche, ça se met à mouliner.
Après avoir checké côté serveur, la requête ne se fait pas seulement sur la colonne date ou timestamp, mais sur la totalité des colonnes : avec plus de deux ans d'archives, ça met le serveur à terre (toutes les colonnes ne sont pas indexées pour ça… ) :
Code : Tout sélectionner
| 760 | jeedom | localhost | jeedom | Query | 37 | Waiting for table level lock | SELECT `timestamp`, `rec_date`, `rec_time`, `hchp`, `hchc`, `ptec`, `inst1`, `imax1`, `papp`, `temp`, `id_equipement`, `timestamp`, `timestamp`
FROM `conso_teleinfo`
WHERE `timestamp` LIKE '%2019/06/14 08:10%' AND `rec_date` LIKE '%2019/06/14 08:10%' AND `rec_time` LIKE '%2019/06/14 08:10%' AND `hchp` LIKE '%2019/06/14 08:10%' AND `hchc` LIKE '%2019/06/14 08:10%' AND `ptec` LIKE '%2019/06/14 08:10%' AND `inst1` LIKE '%2019/06/14 08:10%' AND `imax1` LIKE '%2019/06/14 08:10%' AND `papp` LIKE '%2019/06/14 08:10%' AND `temp` LIKE '%2019/06/14 08:10%' AND `id_equipement` LIKE '%2019/06/14 08:10%' AND `timestamp` LIKE '%2019/06/14 08:10%'
ORDER BY `timestamp` DESC
LIMIT 0, 20 | 0.000 |I
Finalement, ma requête à la mano (19680786 = ancien index, 60 = ID de mon compteur, timestamp récupéré avec un select avant - ou via l'interface) :
Code : Tout sélectionner
UPDATE conso_teleinfo SET hchp = hchp+19680786 WHERE id_equipement=60 AND timestamp >=1560493766 AND timestamp <=1560498572