MySQL (som de fleste DBMS) vil cache eksekveringsplaner for forberedte udsagn, så hvis bruger A opretter en plan for:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(hvor v1 og v2 er bind vars) sender derefter værdier, der skal interpoleres af DBMS, derefter sender bruger B den samme forespørgsel (men med forskellige værdier til interpolation), DBMS behøver ikke at regenerere planen. dvs. det er DBMS, der finder den matchende plan - ikke PDO.
Dette betyder dog, at hver operation på databasen kræver mindst 2 rundrejser (den første for at præsentere forespørgslen, den anden for at præsentere bind vars) i modsætning til en enkelt rundrejse for en forespørgsel med bogstavelige værdier, så introducerer dette yderligere netværksomkostninger . Der er også en mindre omkostning involveret i at dereferere (og vedligeholde) forespørgsels-/plancachen.
Nøglespørgsmålet er, om disse omkostninger er større end omkostningerne ved at generere planen i første omgang.
Selvom der (efter min erfaring) helt sikkert ser ud til at være en ydeevnefordel ved at bruge forberedte udsagn med Oracle, er jeg ikke overbevist om, at det samme gælder for MySQL - dog vil meget afhænge af strukturen af din database og kompleksiteten af forespørgsel (eller mere specifikt, hvor mange forskellige muligheder optimeringsværktøjet kan finde for at løse forespørgslen).
Prøv selv at måle det (tip:du ønsker måske at indstille den langsomme forespørgselstærskel til 0 og skrive noget kode for at konvertere bogstavelige værdier tilbage til anonyme repræsentationer for de forespørgsler, der er skrevet til logfilerne).