MySQL (som de flesta DBMS) cachelagrar exekveringsplaner för förberedda satser, så om användare A skapar en plan för:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(där v1 och v2 är bind vars) skickar sedan värden som ska interpoleras av DBMS, sedan skickar användare B samma fråga (men med olika värden för interpolation) DBMS behöver inte återskapa planen. dvs det är DBMS som hittar den matchande planen - inte PDO.
Detta betyder dock att varje operation i databasen kräver minst 2 tur och retur (den första för att presentera frågan, den andra för att presentera bind vars) i motsats till en enkel tur och retur för en fråga med bokstavliga värden, då introducerar detta ytterligare nätverkskostnader . Det är också en liten kostnad inblandad i att därhänvisa (och underhålla) fråge-/plancachen.
Nyckelfrågan är om denna kostnad är större än kostnaden för att skapa planen i första hand.
Även om det (enligt min erfarenhet) definitivt verkar finnas en prestandafördel med att använda förberedda uttalanden med Oracle, är jag inte övertygad om att detsamma gäller för MySQL - men mycket kommer att bero på strukturen i din databas och komplexiteten i fråga (eller mer specifikt, hur många olika alternativ optimeraren kan hitta för att lösa frågan).
Försök att mäta det själv (tips:du kanske vill ställa in tröskeln för långsam fråge till 0 och skriva lite kod för att konvertera bokstavliga värden tillbaka till anonyma representationer för frågorna som skrivs till loggarna).