ServerPreparedStatementのススメ

MySQL Connector/J

ご存知の通りMySQLではver4.1からサーバにプリペアードステートメントが実装されました．もうここ1ヶ月くらいずっとこの件について調べたりC/Jのコード書いたりしてるわけですが，いろいろ見て見て思うことは，やっぱりこのプリペアードステートメントというのはぜひ使うべきだということ．

ざっくり言って以下のような違いがあります．

  • MySQL client-serverプロトコルで使用するPacketの種類が違う．プリペアードステートメント専用のPacketがある．
  • サーバ側で平のSQL文を解析する手間が発生しない．
  • Connector/J側の処理もclient-prepared-statamentに比べて若干軽い．これは送信するデータが大きければ大きいほど差が出る．

まあ全部根っこは一緒のことですが．MySQL ver4.0系を使っておられる方は，このプリペアードステートメントを使うためという理由でバージョンアップしても良いのではないかというくらいです．←ちゃんとした性能検証による数値的な裏付けがあっていってるわけじゃないですが．

とりあえず，ソースコード的に見た場合，上記に書いた3番目の「送信データが大きい場合」というのの違いはでかいなと思いました．Blob，Clobあるいはストリームを使う場合にはということですね．大きなファイルをMySQLに入れる場合にはということです．まあそんなの当たり前と言われてしまいそうですが．

さてそんなわけで，setNCharacterStreamも大詰め（まだやってたのかという突っ込みは無しで･･･＾＾;）ということで，以下結論．

  • ServerPreparedStatementではそもそもパラメータの長さをlong型で管理しており，setNCharacterStream(int,Reader,long)を追加実装するかといって別に改変しなきゃいけない部分はそもそも無かった．
  • さらに衝撃の事実，実はC/Jは一応パラメータの長さを内部で管理するものの，実際に複数個のLong Data Packetとして送信する部分では「パラメータの長さに依存しないループ処理実装」になっているので，そういう意味でも気にする必要は無かった．

という感じでした．激しく自分乙です．まあMySQLのプロトコル，それとC/Jのプロトコル実装を勉強できたので良しということにさせて下さい･･･ｗ

「結局プロトコルに依存する，というかプロトコルが全て，なんですね」というのが感想．もちろんプロトコル外のコネクタ独自機能（キャッシュ系とか）もいっぱいあるわけですが．何れにしてもこういう感覚を持てるようになったのは収穫かなと．

しかし相変わらず激しく「効率」の悪いことをやっていますな．非常に勉強にはなるもののこんなんでいいのだろうかとも思いつつ，甘えていたり(^^;