Cette fuite de mémoire ne serait un problème que si elle tuait le script avec une erreur "mémoire épuisée". PHP se fera un plaisir de ramasser tous les objets/variables inutilisés par lui-même, mais le collecteur ne démarrera pas tant qu'il n'y sera pas obligé - le ramasse-miettes peut être une opération très coûteuse.
Il est normal de voir l'utilisation de la mémoire grimper même si vous réutilisez constamment les mêmes objets/variables - ce n'est que lorsque l'utilisation de la mémoire dépasse un certain niveau que le collecteur se déclenchera et fera le ménage.
Je soupçonne que vous pourriez accélérer les choses si vous regroupez les ID utilisateur en groupes et publiez moins de mises à jour, en modifiant plus d'enregistrements avec chacun. par exemple. procédez comme suit :
UPDATE user_roundscores SET ursUpdDate=NOW() WHERE ursUserTeamIdFK IN (id1, id2, id3, id4, id5, etc...)
au lieu de le faire une mise à jour par utilisateur. Moins d'allers-retours via la couche d'interface DB et plus de temps sur le serveur =exécution plus rapide.
De plus, considérez l'impact de l'extension maintenant à des millions d'utilisateurs, comme vous le dites dans un commentaire. Un million de mises à jour individuelles prendront un temps non négligeable pour s'exécuter, donc le NOW() ne sera pas une "constante". S'il faut 5 minutes pour faire l'exécution complète, vous obtiendrez une grande variété de ursUpdDate horodatages. Vous voudrez peut-être envisager de mettre en cache un seul NOW() appeler une variable côté serveur et émettre les mises à jour par rapport à cette variable :
SELECT @cachednow :p NOW();
UPDATE .... SET ursUpDate = @cachednow WHERE ....;
