MySQL (както повечето СУБД) ще кешира планове за изпълнение на подготвени оператори, така че ако потребител А създаде план за:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(където v1 и v2 са обвързващи vars) след това изпраща стойности, които да бъдат интерполирани от СУБД, след това потребител Б изпраща същата заявка (но с различни стойности за интерполация) СУБД не трябва да регенерира плана. т.е. СУБД е тази, която намира съвпадащия план, а не PDO.
Това обаче означава, че всяка операция в базата данни изисква поне 2 двупосочни пътувания (първото за представяне на заявката, второто за представяне на vars за свързване), за разлика от едно кръгово пътуване за заявка с буквални стойности, тогава това въвежда допълнителни мрежови разходи . Също така има малка цена, свързана с дерефериране (и поддържане) на кеша на заявката/плана.
Ключовият въпрос е дали тази цена е по-голяма от цената на генериране на плана на първо място.
Въпреки че (според моя опит) определено изглежда, че има полза от производителността при използване на подготвени изрази с Oracle, не съм убеден, че същото важи и за MySQL - обаче много ще зависи от структурата на вашата база данни и сложността на заявка (или по-конкретно колко различни опции може да намери оптимизаторът за разрешаване на заявката).
Опитайте да го измерите сами (подсказка:може да искате да зададете прага за бавна заявка на 0 и да напишете някакъв код за преобразуване на буквалните стойности обратно в анонимни представяния за заявките, записани в регистрационните файлове).
