MySQL（ほとんどのDBMSと同様）はプリペアドステートメントの実行プランをキャッシュするため、ユーザーAが次のプランを作成する場合：
SELECT * FROM some_table WHERE a_col=:v1 AND b_col=:v2
（v1とv2はバインド変数です）次に、DBMSによって補間される値を送信し、ユーザーBは同じクエリを送信します（ただし、補間の値は異なります）。DBMSはプランを再生成する必要はありません。つまり、一致するプランを見つけるのはDBMSであり、PDOではありません。
ただし、これは、リテラル値を使用するクエリの1回のラウンドトリップとは対照的に、データベースの各操作には少なくとも2回のラウンドトリップ（1回目はクエリの提示、2回目はバインド変数の提示）が必要であることを意味します。これにより、追加のネットワークコストが発生します。 。クエリ/プランキャッシュの逆参照（および維持）にはわずかなコストもかかります。
重要な問題は、このコストが最初に計画を作成するコストよりも大きいかどうかです。
（私の経験では）Oracleでプリペアドステートメントを使用するとパフォーマンス上の利点があるように見えますが、MySQLにも同じことが当てはまるとは確信していません。ただし、データベースの構造とデータベースの複雑さに大きく依存します。クエリ（より具体的には、オプティマイザがクエリを解決するために見つけることができるさまざまなオプションの数）。
自分で測定してみてください（ヒント：遅いクエリのしきい値を0に設定し、ログに書き込まれるクエリのリテラル値を匿名表現に変換するコードを記述してください）。