O MySQL (como a maioria dos DBMS) armazenará em cache os planos de execução para instruções preparadas, portanto, se o usuário A criar um plano para:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(onde v1 e v2 são bind vars) então envia valores para serem interpolados pelo DBMS, então o usuário B envia a mesma consulta (mas com valores diferentes para interpolação) o DBMS não precisa regenerar o plano. ou seja, é o DBMS que encontra o plano correspondente - não o PDO.
No entanto, isso significa que cada operação no banco de dados requer pelo menos 2 viagens de ida e volta (a primeira para apresentar a consulta, a segunda para apresentar as variáveis de ligação) em oposição a uma única viagem de ida e volta para uma consulta com valores literais, então isso introduz custos de rede adicionais . Há também um pequeno custo envolvido na desreferenciação (e manutenção) do cache de consulta/plano.
A questão-chave é se esse custo é maior do que o custo de gerar o plano em primeiro lugar.
Embora (na minha experiência) definitivamente pareça haver um benefício de desempenho usando instruções preparadas com Oracle, não estou convencido de que o mesmo seja verdade para o MySQL - no entanto, muito dependerá da estrutura do seu banco de dados e da complexidade do consulta (ou mais especificamente, quantas opções diferentes o otimizador pode encontrar para resolver a consulta).
Tente medir você mesmo (dica:você pode querer definir o limite de consulta lenta como 0 e escrever algum código para converter valores literais de volta em representações anônimas para as consultas gravadas nos logs).
