MySQL (como la mayoría de DBMS) almacenará en caché los planes de ejecución para las declaraciones preparadas, por lo que si el usuario A crea un plan para:
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(donde v1 y v2 son variables de enlace) luego envía valores para ser interpolados por el DBMS, luego el usuario B envía la misma consulta (pero con diferentes valores para la interpolación) el DBMS no tiene que regenerar el plan. es decir, es el DBMS el que encuentra el plan coincidente, no PDO.
Sin embargo, esto significa que cada operación en la base de datos requiere al menos 2 viajes de ida y vuelta (el primero para presentar la consulta, el segundo para presentar las variables de enlace) en lugar de un solo viaje de ida y vuelta para una consulta con valores literales, lo que introduce costos de red adicionales. . También hay un pequeño costo involucrado en la desreferenciación (y el mantenimiento) de la caché de consulta/plan.
La pregunta clave es si este costo es mayor que el costo de generar el plan en primer lugar.
Si bien (en mi experiencia) definitivamente parece haber un beneficio de rendimiento al usar declaraciones preparadas con Oracle, no estoy convencido de que lo mismo sea cierto para MySQL; sin embargo, mucho dependerá de la estructura de su base de datos y la complejidad de la consulta (o más específicamente, cuántas opciones diferentes puede encontrar el optimizador para resolver la consulta).
Intente medirlo usted mismo (sugerencia:es posible que desee establecer el umbral de consulta lenta en 0 y escribir código para convertir valores literales nuevamente en representaciones anónimas para las consultas escritas en los registros).
