prepareメソッドについてメモ

yoku0825 @yoku0825

DBD::MySQLのprepareはPREPAREステートメントじゃなくてクライアントの中でゴニョゴニョしてるだけだよ、と教えてもらった。 試したらマジだった。。

yoku0825 @yoku0825

MySQL本来のPREPAREステートメント、値をバインドする時にユーザー変数に突っ込まないといけないからなんだろうな。。

とみたまさひろ🍣🍺 @tmtms

@yoku0825 prepare 用のプロトコルをちゃんと使えばいいのに

Y.Kentaro @yoshi_ken

@yoku0825 RubyのActiveRecordも、PHPのPDO_MYSQLやMDB2/MySQLもデフォルトの挙動はクライアント側で展開していますよー。

いろ @_iro

@yoku0825 connectするときに何だったか指定すればちゃんとprepareされるはず！ただその場合でもPREPAREステートメント実行するんじゃなくC API叩くんじゃなかったかな（うろ覚え

yoku0825 @yoku0825

@tmtms ∑(ﾟдﾟlll) うわあ知らなかったですよ。。 http://t.co/JqBftVjJE3

yoku0825 @yoku0825

MySQLのえロイ人、Rubyist(?)、Perl Mongerから三者三様に教えていただいた。

yoku0825 @yoku0825

Twitterすごい。

とみたまさひろ🍣🍺 @tmtms

@yoku0825 http://t.co/P5XcTLW3RQ の 52ページ以降とかも。

どぅーあき @do_aki

@yoku0825 手前味噌なれど、 php の pdo についてなら http://t.co/OkaqgocEkT を参照していただけると。デフォルトでは prepared statement はクライアント側でエミュレートされますです。

Ryuta Kamizono @kamipo

@yoku0825 DBD::mysql、PREPAREステートメントいちおうサポートしてるんですけど、一般的なWebアプリケーションだとPREPAREしたのを何度も使いまわせる作り方をしないのでクエリ数が約2倍になってネットワークのレイテンシが乗って遅くなると理解してます。

yoku0825 @yoku0825

@kamipo ∑(ﾟдﾟlll) そういえば、そうですね。。

yoku0825 @yoku0825

ありがたやありがたや。

Kazuho Oku @kazuho

@yoku0825 @kamipo Javaなどの場合でも、少なくとも数年前はサーバサイドプレペアは非推奨だったかと。ステートメントの解析結果を保存するサーバサイドの情報のexpireができない（接続が切断されるまで）とか、実行プランをキャッシュするわけではないので速度向上小とか

yoku0825 @yoku0825

1:Nレプリケーションの人がちゃんとぺちぱーをやっていた瞬間。。 PHP と MySQL と サーバサイド プリペアードステートメント - do_akiの徒然想記 http://t.co/q5cO7DwsFS

yoku0825 @yoku0825

@kazuho @kamipo MySQLに限らず、WEBシステムでは…って感じになる(だった)んでしょうか。そしてアレ、パースまで終わらせておくのかオプティマイズまで終わらせておくのかが実装ごとにかなり違いそうな予感がします。。

Kazuho Oku @kazuho

@yoku0825 @kamipo MySQL のサーバサイドプリペアードステートメントの問題については http://t.co/B5xGSdnVZw が詳しいかと思います。今は違うのかも

methane @methane

@kazuho @yoku0825 @kamipo 実行計画建てるのにその時の統計情報使うからキャッシュしにくいという認識。

Kazuho Oku @kazuho

@methane @yoku0825 @kamipo 実行プランたてるたびに統計情報を更新してるRDBMS実装ってあるんでしょうか。少なくともInnoDBはしてなかったはず

SH2 @sh2nd

@kazuho @methane @yoku0825 @kamipo Oracle 11gR2以降でCardinality Feedbackという機能があります。ただし毎回ではなく「どうもおかしい」と思ったときのみ発動します。PDF→ http://t.co/lygty45GOX