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