Il y a une petite chose à mentionner. Par défaut, PDO se contente d'émuler instructions préparées.
Et en mode émulation, il exécute la même ancienne requête sans réellement préparer une seule instruction :)
Alors, tout d'abord,
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, FALSE);
pour activer les vrais relevés préparés.
Il y a une autre petite chose à mentionner.
Malheureusement, il y a très peu de vrais connaissances dans le monde. Et surtout dans le monde des sites de questions-réponses. Les gens ont tendance à répéter les informations qu'ils avaient lues et jugées raisonnables. Sans effectuer de tests pour prouver ou même sans mettre la main dessus. Ainsi, "souvent noté" ne devrait pas du tout être considéré comme une source fiable.
Revenons à la question :même s'il devrait y avoir une pénalité, elle devrait être insignifiante la plupart du temps. Si c'est le cas, vous devez régler votre système.
Quoi qu'il en soit, en mode émulation, vous l'avez à la fois "rapide" et sûr.
Mettre à jour
Eh bien, après avoir exécuté vos tests sur mes données, je dois dire qu'il y a quelque chose qui ne va pas avec votre base de données si vous avez une différence de 3 fois sur un grand ensemble de données.
Pour une requête éclair
select title from Board where id = 1
les résultats sont
emulation on off
query 0.07 0.130
prepare 0.075 0.145
tandis que pour la requête assez lourde
select title from Board where id > 1
les résultats sont
emulation on off
query 0.96 0.96
prepare 0.96 1.00
Ainsi, comme nous pouvons le voir, sur un grand ensemble de données, la différence devient imperceptible.
Pour la requête éclair, il y a une certaine différence, mais, comme cela ne prend que 0,0003ème faction de seconde (pour une seule requête) - je dirais que c'est un exemple parfait pour le mot "indifférence".
Pour des résultats égaux entre query()/prepare() - je n'ai qu'une idée - PDO utilise prepare/execute pour toutes les requêtes, même celles sans liaisons.
Passons maintenant au problème d'encodage.
Oui, le problème bizarre de GBK affecte PDO pour les versions antérieures à 5.3.3. Ces versions n'avaient aucun moyen de définir le bon encodage et étaient inévitablement vulnérables (en mode émulation). Mais depuis la version 5.3.3, PDO prend en charge la définition de l'encodage dans DSN, et maintenant tout va bien.
Pour mysqli, il faut utiliser mysqli_set_charset() dans ce but précis avec le même résultat (impénétrable).
Dans ma propre classe basée sur mysqli, j'utilise ma propre implémentation d'espace réservé et je n'utilise aucune instruction préparée. Pas pour des raisons de performances mais pour une meilleure fiabilité.
