MySQL (comme la plupart des SGBD) mettra en cache les plans d'exécution pour les instructions préparées, donc si l'utilisateur A crée un plan pour :
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
(où v1 et v2 sont des variables liées) envoie alors des valeurs à interpoler par le SGBD, puis l'utilisateur B envoie la même requête (mais avec des valeurs d'interpolation différentes) le SGBD n'a pas à régénérer le plan. c'est-à-dire que c'est le SGBD qui trouve le plan correspondant - pas PDO.
Cependant cela signifie que chaque opération sur la base de données nécessite au moins 2 allers-retours (le 1er pour présenter la requête, le second pour présenter les variables liées) par opposition à un seul aller-retour pour une requête avec des valeurs littérales, alors cela introduit des coûts de réseau supplémentaires . Il y a aussi un petit coût impliqué dans le déréférencement (et la maintenance) du cache de requête/plan.
La question clé est de savoir si ce coût est supérieur au coût de génération du plan en premier lieu.
Bien que (d'après mon expérience), il semble y avoir un avantage en termes de performances en utilisant des instructions préparées avec Oracle, je ne suis pas convaincu qu'il en va de même pour MySQL - cependant, cela dépendra beaucoup de la structure de votre base de données et de la complexité du requête (ou plus précisément, combien d'options différentes l'optimiseur peut trouver pour résoudre la requête).
Essayez de le mesurer vous-même (indice :vous pouvez définir le seuil de requête lente sur 0 et écrire du code pour reconvertir les valeurs littérales en représentations anonymes pour les requêtes écrites dans les journaux).
