Prepared statementを使うとQuery cacheが効かない

4.1の日本語化されたマニュアルばかり読んでいたらこの動作への言及が無かったため見落していたが、5.0に対応したオリジナルである英語版にはちゃんと注意が書いてあった。
道理ででnot_cachedばかりが増えていくわけだ。それだけコード側でのprepared statementの利用が徹底されているということは、それはそれで良いのだけど、どうしよう。繰り返し利用しないようなSQLでパラメータも固定のものはprepareしないでいきなり実行するように書き換えてしまうべきか。無論、Injection対策になる部分を無理矢理書き換える必要はないんだけど。
機能として同じような場所で動くものだから協調して動作させるのが難しそうではあるが、本質的に共存不可能なものではないので実装自体が改善してくれると嬉しい。
(追記)
よくよく考えると共存はかなり面倒な実装になりそう。そもそもPrepared statementというのは構文解析済みのクエリを保持しておく仕組みだが、後からパラメータを渡されて実行する時点ではSQLは解釈済みで原形を留めていないはず。
それに対してQuery cacheの現在の実装はSQLの完全一致したときにキャッシュが効くようになっていることからも分る通り、構文解析の前段階。恐らくSQLを受け取った直後に動作するようになっていると思われる。これは構文解析の処理もキャッシュするという意味で意義がある。だけど、先のPrepared statementとは動く段階が構文解析の前と後と違う。
そもそもprepared statementも協調動作を意識した動作にするために、構文解析後も元のSQLを同じく保持しておかなければならなくなる。そこまでやったとしても、解析済みの文に対して異なるパラメータを渡されて実行する度に違うエントリのキャッシュが増えてしまう。それならいっそprepared statementを使われたら一律にキャッシュ対象から外すという現在の実装はそれなりに理にかなっているのかも。