追記：「1行の大きさの制約の65535バイトを4バイトまで拡張する」が意味不明だったのを修正しました。1行のサイズを2バイトで管理している関係で、通常のMySQLではBLOB型などを除外した1行のデータサイズが256^2-1=65535バイトまでに制限されているのですが、これを4バイトで管理するようにして上限を256^4-1=4294967295バイトにするパッチを作ったよ、ということです。
8/7にGREEさんで開催された、第18回オープンソーステクノロジー勉強会に参加してきました。ひどい雨にも関わらず大盛況でした。久々の参加でしたが、司会をつとめた一井さんはじめGREEスタッフの方々、毎度ありがとうございます。
この日は、「MySQLハッキングの手引き」と題して、MySQLの機能をCレベルでカスタマイズするという内容の講演でした。スピーカーはMySQLカンファレンスでMySQLのインデックスチューニングの話をしていた松信さんでした。1時間の予定が大幅に伸びていましたが、濃い内容でした。
MySQLは利用者も多く、後方互換性の確保に気を遣っているため、MySQL本体への変更はなかなか受け入れられないそうです。その代わり、バージョンアップごとにプラグイン化を進めており、本体への変更なしに挙動を変えられる範囲が徐々に広くなっているそうです。
プラグインの実例として、UDF（ユーザー定義関数）を作成する話題がありましたが、非常に興味深いものでした。かなりざっくり説明すると、あるqueryの結果を元にもう1query投げる必要があるような場合に、queryを投げる代わりにUDFを利用してストレージエンジンAPI経由で検索すると高速になるよ、というものでした。
UDF経由でストレージエンジンAPIを叩くメリットは、SQL文を投げた場合に比べてSQL文の構文解析と実行計画の2フェーズを省略できることです。デモでは、この効果により10倍近い高速化を実現していました。10倍というのは少々作為的な例だったような気もしますが、実案件でも生かせる場所がありそうな話題だと感じました。
また、MySQL本体に手を入れる例として、1行の大きさの制約の65535バイトを4バイト 4294967295バイトまで拡張する、という話題もありました。その気になれば制約を変えられるというのは面白い話題ですよね。講演後に「実際には1行が65535バイトを超えるようなテーブル定義にするくらいならtext型とかを使った方が有利だったりしませんか？」と聞いてみたら、そんな気もするけど、実際に顧客からの要望で実現したとかそんなお話を伺いました。
実装レベルの話題として、環境依存を避けるためにファイル保存や通信など、すべてリトルエンディアンに統一している、という話も出ました。おそらく、これを知らないとCのコードが書けないということなんでしょう。ソースコードをチラッとみた感じでは、2バイトや4バイトの値をファイルに記録したり読み出したりする場合には常に専用の関数が必要そうに見えました。
そんな話題を伝えてくれたのも、聴衆である僕らにMySQLのコードを書いて欲しいという思いがあったのでしょう。僕も久々にCとかC++とかのコードが書きたくなってきました。
あと、MySQLへのバグレポは簡単だからみんなしてね！というのも良い話題でしたね。僕もPHP本体のバグレポのネタで何度か話しているので、「やってみたら簡単だよ」を伝えたい気持ちはとてもわかります。
ベンチマークツールとしてSuper Smackを使ってるよ、という話題も出ましたね。恥ずかしながら初耳だったので、また今度試そうと思います。
