MySQL (zoals de meeste DBMS) slaat uitvoeringsplannen op voor voorbereide instructies, dus als gebruiker A een plan maakt voor:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(waarbij v1 en v2 bind-vars zijn) verzendt vervolgens waarden die door de DBMS moeten worden geïnterpoleerd, vervolgens verzendt gebruiker B dezelfde query (maar met verschillende waarden voor interpolatie) de DBMS hoeft het plan niet opnieuw te genereren. d.w.z. het is de DBMS die het overeenkomende plan vindt - niet de PDO.
Dit betekent echter dat elke bewerking op de database ten minste 2 retourvluchten vereist (1e om de query te presenteren, de tweede om de bind-vars te presenteren) in tegenstelling tot een enkele retour voor een zoekopdracht met letterlijke waarden, dan introduceert dit extra netwerkkosten . Er zijn ook kleine kosten verbonden aan het dereferentie (en onderhoud) van de query/plan-cache.
De belangrijkste vraag is of deze kosten hoger zijn dan de kosten om het plan in de eerste plaats te genereren.
Hoewel er (naar mijn ervaring) zeker een prestatievoordeel lijkt te zijn bij het gebruik van voorbereide instructies met Oracle, ben ik er niet van overtuigd dat hetzelfde geldt voor MySQL - veel zal echter afhangen van de structuur van uw database en de complexiteit van de query (of meer specifiek, hoeveel verschillende opties de optimizer kan vinden om de query op te lossen).
Probeer het zelf te meten (hint:u kunt de drempel voor langzame zoekopdrachten op 0 zetten en wat code schrijven om letterlijke waarden terug om te zetten in anonieme representaties voor de zoekopdrachten die naar de logboeken worden geschreven).