Real UTF-8 On MySQL 6.0

現在のバージョンのMySQLでは、UTF-8を完全にはサポートしていない。

というと、そのことを知らなかった人は驚くかも知れない。UTF-8は1文字あたり1〜4バイトのサイズを消費する可変長文字コードなのだが、MySQLのUTF-8では4バイトを消費するようにマッピングされている文字を格納したり、取り扱ったりすることが出来ないのだ。（厳密にいうとUTF-8では6バイトまで定義できることになっているが、文字の割り当ては4バイト目までである。）MySQL 5.xまでで対応しているのは、3バイトにマッピングされた文字までである。

UTF-8はUnicodeの符号化方式の一種なので、基本的に世界各国の言語をUnicodeだけで扱うことができる。日本語に関していえば、4バイト目に割り当てられた文字は第3、第4水準漢字だけなので、3バイト目までしか使えなくても実用上は問題がないように見える。しかし地名や人名でこれらの漢字が使われていることが多々あり、そのような場合に文字を入力できないと困るので、そのようなデータを扱う必要があるシステム（役所など）は4バイト目まで対応している必要がある。

というわけでMySQLもようやく次の次のバージョンである6.0からUTF-8が4バイト対応になる。MySQL 6.0ではutf8といえば4バイトの文字コードを指し、これまでの3バイトしか扱えない文字コードはutf8mb3という名前で互換性のために残されている。既存のデータをそのまま扱いたい場合には、このutf8mb3を使うといいだろう。

utf8が4バイト文字対応になってやっかいなのが、文字列型カラムの最大サイズだろう。CHARなどでは必ず文字数の4倍のバイト数のスペースが確保されてしまうことになる。例えばCHAR(10)は40バイト必要になる。これではスペースをかなり無駄遣してしまうので、CHARではなくVARCHARを使えばいいじゃないか？！と思うかも知れないが、問題はそれほど単純ではない。MEMORYなど固定長のカラムしか対応していないストレージエンジンでは、スペースの無駄遣いは避けられないからだ。MEMORYストレージエンジンの例では、この影響でテンポラリテーブルがこれまでより早く成長して閾値に達するので、これまでより早くMyISAMに変換されることが予想される程度の影響で済む。（対策としてはmax_heap_table_sizeおよびtmp_table_sizeを少し大きくしておけばいいだろう。MySQL 6.0が正式にリリースされる頃にはメモリの価格ももっと下落しているハズなのでモウマンタイである！！）しかしMySQL Clusterのディスクテーブルなど、固定長のスペースを必要とする箇所は他にも潜んでいるので油断がならない。（ディスクテーブルも将来的にはVARCHARの領域が可変長化する予定だ。）

MySQL 6.0はまだα版の段階なので動作は少し不安定なところもある。しかし不安定なのは主にFalconなどバージョン6.0で追加された箇所だけなので、それらの機能を使わずutf8を試すだけならば比較的安定して動作する。なのでMySQLを将来的にも使用し続ける予定であるなら、ぜひ早い段階でMySQL6.0の4バイト対応utf8を試していただきたい。