MySQLのBIT_LENGTH()関数はマルチバイトセーフか？LENGTH()との違いを具体例で解説

BIT_LENGTH()関数はマルチバイトセーフではない

MySQLのBIT_LENGTH()関数は、LENGTH()関数と同じくマルチバイトセーフ（マルチバイト対応）ではありません。つまり、この関数が返すのは「文字数」ではなく「ビット数（バイト数×8）」であり、文字コードの種類によって結果が大きく変わります。

マルチバイトセーフなCHAR_LENGTH()やCHARACTER_LENGTH()との違いは、特に以下のようなケースで重要になります。

• Unicode（ucs2など）：ほとんどの文字が2バイトでエンコードされる
• UTF-8：文字によって必要なバイト数が1〜4バイトと異なる

具体的な動作を、以下の例で確認してみましょう。

例：通常の文字列に対するBIT_LENGTH()

mysql> Select BIT_LENGTH('tutorialspoint');
+------------------------------+
| BIT_LENGTH('tutorialspoint') |
+------------------------------+
|                          112 |
+------------------------------+
1 row in set (0.00 sec)

上記の結果セットを見ると、文字列「tutorialspoint」のビット長は112と表示されています。これは、14文字 × 8ビット = 112ビットという計算になり、まだUnicodeに変換されていない状態（1文字 = 1バイト = 8ビット）で評価されているためです。

例：Unicodeに変換した場合のBIT_LENGTH()

次のクエリを実行すると、文字列をUnicode（ucs2）に変換できます。

mysql> SET @A = CONVERT('tutorialspoint' USING ucs2);
Query OK, 0 rows affected (0.02 sec)

変換後の変数@Aに対してBIT_LENGTH()を実行すると、結果は224になります。

mysql> Select BIT_LENGTH(@A);
+----------------+
| BIT_LENGTH(@A) |
+----------------+
|            224 |
+----------------+
1 row in set (0.00 sec)

これは、Unicode（ucs2）では1文字あたり2バイト（16ビット）を使用するためです。14文字 × 16ビット = 224ビットとなり、変換前の112の倍になっていることがわかります。

まとめ：文字数を知りたい場合はCHAR_LENGTH()を使う

このように、BIT_LENGTH()やLENGTH()は文字コードの影響を直接受けるため、日本語などのマルチバイト文字を含むデータを扱う際には注意が必要です。単純に「文字数」を取得したい場合は、マルチバイトセーフなCHAR_LENGTH()またはCHARACTER_LENGTH()を使用するのが安全です。逆に、ストレージサイズや転送データ量を見積もりたい場合には、BIT_LENGTH()やLENGTH()が役立ちます。用途に応じて適切な関数を使い分けましょう。