Wanneer een verzoek wordt ingediend, "schoont" php de instantie op en maakt bronnen en andere variabelen vrij. Dit gebeurt in verschillende stappen. Omdat fastcgi het proces levend houdt na een verzoek, worden niet alle stappen uitgevoerd en wordt niet al het geheugen vrijgemaakt. Er is b.v. EG(persistent_list) die wordt gebruikt door mysql_pconnect()
, pg_pconnect()
, ... Deze lijst wordt niet leeggemaakt tussen verzoeken zolang het proces in leven blijft (kan zijn, afhankelijk van de daadwerkelijke implementatie, maar dat zou het doel van EG (persistent_list) tarten). Als u permanente verbindingen gebruikt, kan uw script een "hergebruikte" verbinding tot stand brengen tijdens een eerdere aanvraag.
Om een voorbereide instructie rechtstreeks te (her)gebruiken, hebt u de identifier voor die instructie (en die verbinding) nodig. Bij gebruik van (php-)postgresql is dit gewoon een (verbindingsgewijze) unieke string die u doorgeeft aan pg_execute() , dus uw script heeft geen probleem om toegang te krijgen tot de instructie die eerder door een andere instantie is opgesteld (met dezelfde verbinding).
Met behulp van mysqli
of PDO-mysql
je hebt een resource/object nodig als statement-ID. Dat is nogal een probleem, aangezien noch de mysqli, noch de pdo-extensie een manier lijkt te bieden om de bron in EG(persist_list) tussen verzoeken op te slaan en je kunt het ook niet opnieuw maken. Tenzij php-fpm zo'n "service" biedt, lijkt het onmogelijk om een door mysql opgesteld statement rechtstreeks opnieuw te gebruiken.
Het enige waar je op kunt hopen is MySQL's server-side query cache
. In recente versies (zie link) kan het de verklaring herkennen bij het gebruik van voorbereide verklaringen. Maar zelfs dan wordt de eigenlijke voorbereide verklaring niet opnieuw gebruikt:
Dus als ik me niet vergis, kun je momenteel geen mysql-statement hergebruiken dat is opgesteld tijdens een eerder verzoek in php.