データベースの VARCHAR 長設計｜文字数制限のベストプラクティス
データベース設計において、VARCHAR カラムの長さをどう決めるかは見過ごされがちですが、パフォーマンスとデータ品質に直結する重要な判断です。安易に VARCHAR(255) を設定するのではなく、データの性質に合った適切な長さを選びましょう。
VARCHAR と CHAR の違い
文字列型を選ぶ際、まず VARCHAR と CHAR の違いを理解しておく必要があります。
| 特性 | CHAR(n) | VARCHAR(n) |
|---|---|---|
| 格納方式 | 固定長 (空白で埋める) | 可変長 (実際の長さ分のみ) |
| ストレージ | 常に n バイト消費 | 実データ + 1〜2 バイト |
| 適した用途 | 国コード、郵便番号など固定長データ | 名前、メールアドレスなど可変長データ |
| 検索速度 | 固定長のため若干高速 | 可変長のためわずかにオーバーヘッド |
大半のケースでは VARCHAR が適切です。CHAR を使うのは、ISO 国コード (CHAR(2)) や通貨コード (CHAR(3)) のように長さが完全に固定されたデータに限定しましょう。
主要 RDBMS の VARCHAR 上限比較
RDBMS によって VARCHAR の最大長や単位 (文字数 / バイト数) が異なります。
| RDBMS | 最大長 | 単位 | 備考 |
|---|---|---|---|
| MySQL 8.0 | 65,535 バイト | 文字数指定 | 行全体で 65,535 バイトの制限あり |
| PostgreSQL | 約 1 GB | 文字数指定 | VARCHAR と TEXT の性能差はほぼなし |
| SQL Server | 8,000 バイト | 文字数指定 | VARCHAR(MAX) で約 2 GB まで |
| Oracle | 4,000 バイト | バイト or 文字 | MAX_STRING_SIZE で 32,767 バイトに拡張可 |
| SQLite | 制限なし | — | 型宣言は参考情報として扱われる |
文字数とバイト数の関係
UTF-8 エンコーディングでは、文字の種類によって 1 文字あたりのバイト数が異なります。VARCHAR の長さを文字数で指定する RDBMS でも、内部的にはバイト数の制約を受ける場合があります。
| 文字の種類 | UTF-8 バイト数 | 例 |
|---|---|---|
| ASCII 英数字 | 1 バイト | a, Z, 0, @ |
| ラテン拡張・キリル文字 | 2 バイト | é, ñ, Д |
| 日本語 (ひらがな・カタカナ・漢字) | 3 バイト | あ, ア, 漢 |
| 絵文字・特殊記号 | 4 バイト | 😀, 🎉, 𠮷 |
日本語を格納するカラムでは、VARCHAR(100) と指定しても実際には最大 300 バイトを消費する可能性があります。文字カウンタスでバイト数を確認しながら設計すると、想定外のデータ切り詰めを防げます。
カラム長設計のベストプラクティス
適切な VARCHAR 長を決めるための指針を整理します。
| データ項目 | 推奨長 | 根拠 |
|---|---|---|
| メールアドレス | VARCHAR(254) | RFC 5321 の上限が 254 文字 |
| 氏名 (日本語) | VARCHAR(50) | 姓名合わせて 50 文字あれば十分 |
| 電話番号 | VARCHAR(20) | 国際番号を含めても 15 桁 + 記号 |
| URL | VARCHAR(2048) | 主要ブラウザの URL 長上限 |
| 住所 | VARCHAR(200) | 日本の住所は通常 100 文字以内 |
| 商品名 | VARCHAR(200) | EC サイトの一般的な上限 |
- データの仕様や標準規格がある場合は、その上限に合わせる。
- 仕様がない場合は、実データの最大長に 20〜50% のマージンを加える。
- 将来の拡張を見越しつつ、過度に大きな値は避ける。
- アプリケーション側でも同じ文字数制限のバリデーションを実装する。
まとめ
VARCHAR 長の設計は、データの性質・エンコーディング・RDBMS の仕様を総合的に考慮して決定すべきです。「とりあえず 255」ではなく、根拠のある長さを設定することで、ストレージ効率とデータ品質の両方を高められます。設計段階で想定データの文字数を文字カウンタスで計測し、適切なカラム長を導き出しましょう。