データベース管理者として現場に立っていると、しばしば遭遇するのが「文字列の長さ」に関するトラブルです。特に、MySQLやPostgreSQLといったRDBMSにおいて、LENGTH関数がバイト数を返す仕様であることは、実務において非常に重要な注意点となります。今回は、単なる仕様解説ではなく、実運用で起こりがちなトラブルを回避するための視点をお伝えします。
なぜ「文字数」ではなく「バイト数」なのか
多くの開発者が「LENGTH」という名前から、直感的に「文字数」を期待してしまいます。しかし、UTF-8環境において日本語（全角文字）は1文字が3バイトまたは4バイトで構成されることが一般的です。例えば「あいうえお」という5文字の文字列に対し、LENGTH関数を適用すると15バイトという結果が返ります。バリデーションチェックの際、この「バイト数」と「文字数」の乖離を考慮せずに実装を進めると、致命的な問題に繋がります。
実務で発生する典型的な「想定外」
最も危険なのは、カラムの最大許容バイト数を超えてデータが切り捨てられる（あるいはエラーになる）ケースです。例えば、VARCHAR(10)のカラムに「あいうえお」を入れようとした場合、文字数としては5ですが、UTF-8では15バイト必要となります。この時、LENGTH関数のみでバリデーションを掛けていると、システム側は「10バイト以内」という制約を意図しているにも関わらず、実際には3文字程度しか入らないという仕様上の不整合が発生します。
また、絵文字の混入も無視できません。最近のモバイルアプリでは、4バイトを消費する絵文字が多用されます。LENGTH関数で計算した際に、想定していたバイト数よりも大きくなり、データベースの制約に引っかかってAPIが500エラーを返すという事態は、DBAとして何度も目にしてきました。
解決策：目的によって関数を使い分ける
実務においては、以下のルールを徹底することをお勧めします。
まず、「物理的な格納容量」をチェックしたい場合には、そのままLENGTH関数を使用してください。これはマイグレーションやディスク容量予測において必須の指標です。
次に、「入力文字数」を制御したい場合は、各DBが用意している文字数カウント関数を使うべきです。MySQLであればCHAR_LENGTH関数、PostgreSQLであればchar_length関数やcharacter_length関数がこれに該当します。これらはマルチバイト文字を「1」としてカウントするため、フロントエンドの入力制限と論理的な整合性を保つことができます。
まとめ：DBAとしての提言
DBAとして、開発チームには「LENGTH関数はバイト単位である」という事実を、設計段階で強く周知しておく必要があります。もし既存のシステムで「なぜか特定のデータだけ保存できない」という事象が発生した際は、まずそのカラムの定義（バイト数制限）と、アプリケーション側で文字数チェックを行っている関数の種類を確認してください。
技術的な仕様を正しく理解し、目的に応じて関数を使い分けること。これこそが、堅牢なデータベースを維持するための第一歩です。日々の運用において、安易な関数選択が大きな障害を招くことを常に意識しておきましょう。
コメント