MySQLにおけるvarchar(255)とvarchar(256)の違い

なぜ256でなく、255が多いのか調べると、情報がバラバラで本質的な情報が埋もれていたので簡潔にまとめます。

結論

  • varcharの長さ(バイト数)によって、先頭1バイトが2バイト必要になるなどの情報は無視して良い。
  • utf-8を格納するならvarchar(255)にしておいたほうが良い。
  • utf-8mb4で格納するならvarchar(255)とvarchar(256)に違いはない。
  • utf-8mb4で格納するならvarchar(191)以下にしたほうが良い。

上記について、追って説明していきます。

なぜ先頭バイトの話を無視してよいか

「MySQL varchar(255) varcar(256)」などで検索すると、varchar型の文字列長についての記事が散見されます。エンジニアとして知っておいても良いですが、実運用上ではほぼ意味のない議論です。

なぜならば、データ量1バイトの違いであるからです。1バイトのオーバヘッドは、1億行程度入って初めて1GBですよ? 今のご時世に1GBでをそこまで気にする環境も珍しいかと思います。よって、長さ議論は無視して良いです。

さらにいうと、utf-8でデータが格納されることを想定した場合に、255か256かで議論するのも不毛です。そもそも文字コードがutf-8の場合は1文字あたり3バイトなので、86文字を超えた時点で先頭2バイトを利用して列の長さ(バイト数)を表現します。そもそも、utf-8で86文字入れようとした時点で先頭の2バイトを利用しているのですね。

なぜutf-8を格納するならvarchar(255)にするのか

UNIQUE KEYもしくはPRIMARY KEYの場合に、インデックスが作成できなくなるためです。こちらの記事にも記載があるように、767バイトでフィールド長制限があります。utf-8の場合は、1文字3バイトですので、256文字(=768バイト)で制限を超えます。

utf-8mb4ではなく、utf-8の場合だという点に注意が必要です。

なぜutf-8mb4ならvarchar(191)以下なのか

1文字の換算が、utf-8は3バイトで、utf-8mb4が4バイトであるためです。上述した767バイトの制限があるため、インデックスを貼る場合は、191文字(=764バイト)が良いです。

あとがき

いろいろ記載しましたが、そもそも数百文字の値が入るカラムに対して、PK制約やUNIQUE制約をかけること自体がナンセンスな気がします。データサイズに合わせたカラム設定を行うべきでしょう。もし、何も考えずに設定するなら、今後は191以下で、といった感じでしょうか。

MySQL