Ten wyciek pamięci byłby problemem tylko wtedy, gdyby zabijał skrypt błędem „wyczerpanie pamięci”. PHP z radością sam zbierze wszystkie nieużywane obiekty/zmienne, ale kolektor nie wykopie, dopóki nie będzie musiał - odśmiecanie może być bardzo kosztowną operacją.
To normalne, że zużycie pamięci rośnie, nawet jeśli ciągle używasz tych samych obiektów/zmiennych – dopiero wtedy, gdy zużycie pamięci przekroczy pewien poziom, kolektor uruchomi się i posprząta dom.
Podejrzewam, że możesz przyspieszyć działanie, jeśli podzielisz identyfikatory użytkowników na grupy i wydasz mniej aktualizacji, zmieniając w każdej z nich więcej rekordów. np. wykonaj następujące czynności:
UPDATE user_roundscores SET ursUpdDate=NOW() WHERE ursUserTeamIdFK IN (id1, id2, id3, id4, id5, etc...)
zamiast robić to po jednej aktualizacji na użytkownika. Mniej podróży w obie strony przez warstwę interfejsu DB i więcej czasu na serwerze =szybsze działanie.
Rozważ również wpływ rozszerzenia tego na miliony użytkowników, jak mówisz w komentarzu. Uruchomienie miliona pojedynczych aktualizacji zajmie nietrywialną ilość czasu, więc NOW() nie będzie „stałą”. Jeśli wykonanie pełnego uruchomienia zajmie 5 minut, otrzymasz szeroką gamę ursUpdDate znaczniki czasu. Możesz rozważyć buforowanie pojedynczego NOW() wywołaj zmienną po stronie serwera i wydaj aktualizacje dla tej zmiennej:
SELECT @cachednow :p NOW();
UPDATE .... SET ursUpDate = @cachednow WHERE ....;
