SQLのtext型をDBMS別に徹底解説：MySQL・PostgreSQL・SQL Server・SQLiteの違いと実践的な使い分け
エバープレイ編集部はじめに
SQLにおける「text型」は、長い文字列データを扱うための代表的なデータ型です。しかし「text型」と一言で言っても、RDBMS（MySQL、PostgreSQL、SQL Server、SQLiteなど）ごとに意味合いや実装、制約が異なります。本稿では各DBMSごとの実装差、内部保存やインデックス、パフォーマンス面、設計上の注意点、実践的な使い分けまで詳しく解説します。
SQLの「text型」とは（概念）
一般に「text型」は可変長の文字列を格納するための型で、VARCHARのように最大長を限定しない（あるいは非常に大きな上限を持つ）ことが特徴です。大容量の文章、ログ、HTML、JSONライクな長文などを格納する用途で用いられます。多くの実装ではCLOB（Character Large Object）に相当しますが、実装や制限はDBMS依存です。
MySQLにおけるTEXT
種類と上限（バイト単位）:
- TINYTEXT: 最大 255 バイト
- TEXT: 最大 65,535 バイト（約64KB）
- MEDIUMTEXT: 最大 16,777,215 バイト（約16MB）
- LONGTEXT: 最大 4,294,967,295 バイト（約4GB）
注意：これらはバイト数での上限です。utf8mb4 等のマルチバイト文字セットを使う場合、格納できる文字数はバイト数／1文字あたりのバイト数に依存します。
デフォルト値:
MySQLではBLOB/TEXT型のカラムにデフォルト値を設定できません（NULLか明示的にINSERTで指定する形になります）。
ストレージと性能:
InnoDBでは長いTEXTは行外に格納されポインタが行内に保存される（row format に依存し、先頭部分を行内に保持する実装がある）ため、短い文字列と比較してI/Oやテーブル書き換えコストが異なります。インデックスについては長さ制限があり、接頭語インデックス（例：INDEX(col(100))）で対応するケースが一般的です。全文検索を行う場合はFULLTEXTインデックスや外部の検索エンジンを使うことが多いです。
利用時の注意:
- 行サイズや文字セットによる実効上限に注意する。
- 頻繁に検索の対象にする大容量テキストはパフォーマンス問題になりやすい（全文検索用インデックスや専用検索エンジンを検討）。
PostgreSQLにおけるtext
基本特性:
PostgreSQLのtext型は可変長で「長さを指定しない文字列」型として扱われ、事実上非常に大きな文字列を格納できます。内部ではTOAST（The Oversized-Attribute Storage Technique）により大きな値は自動的に行外に格納されます。理論上のカラムサイズ上限は約1GB程度（PostgreSQLの個々のフィールドは約1GBの制約）です。
デフォルト・操作:
text型はVARCHAR(n)とほぼ同等の振る舞い（長さ制限がない点で異なる）で、デフォルト値も設定可能です。文字列操作関数、正規表現、ILIKE（大文字小文字を無視したLIKE）などが利用できます。
インデックスと全文検索:
PostgreSQLではbtreeインデックスでtextを扱うことができますが、全文検索には組み込みの全文検索機能（to_tsvector / to_tsquery と GINインデックス）や trigram（pg_trgm 拡張）による高速な部分一致検索を活用するのが一般的です。
SQL ServerのTEXT（と現代的な代替）
TEXTの扱い:
歴史的にSQL Serverにはtext/ntextという大きなテキスト型がありましたが、これらは非推奨（deprecated）で、現在は VARCHAR(MAX) / NVARCHAR(MAX) の使用が推奨されています。VARCHAR(MAX) は最大 2^31-1 バイト（約2GB）まで格納可能です。
全文検索:
SQL Serverもフルテキスト検索機能を持ち、大きなテキストカラムに対して専用の全文検索インデックスを張ることができます。
SQLiteにおけるTEXT
型アフィニティ:
SQLiteでは型システムが緩く、カラム宣言にTEXTと書いても厳密な固定長制約はありません。SQLiteの文字列長上限はコンパイル時定数（デフォルトは大きな値、通常は約1,000,000,000バイト）に依存します。実運用ではアプリ側で制約を設けることが多いです。
text型とvarcharなどの使い分け
短い文字列（名前、メールアドレスなど）→ VARCHAR(n) や固定長CHARが適切。明確な上限があることでメモリやインデックスの効率が良く、意図しない巨大データの混入を防げます。
長文（記事本文、ログ、コメントなど）→ TEXT / CLOB 系を選択。頻繁に全文検索を行うなら専用の全文検索インデックスやElasticsearch等を検討。
検索性とインデックスの必要性を考える。大きなtextを頻繁にWHEREやORDER BYで使う場合は、部分的なインデックス（接頭語）や別カラムに要約を保持するなどの工夫が必要。
パフォーマンス・運用上の注意点
バックアップ／リストアやレプリケーションで大容量カラムはオーバーヘッドになる。頻繁に更新される大容量カラムはWAL（Write-Ahead Log）やレプリケーションの負荷を高める。
テーブル設計時に大きなテキストを多用するとテーブルリライト（ALTER TABLE 等）が重くなることがある。スキーマ変更時のコストを事前に検討する。
文字セットと照合順序（collation）に注意。utf8mb4などマルチバイトを使う場合、サイズ計算はバイト単位である点を意識する。
インデックスはサイズ制限や性能特性がある。長いTEXTに対する等価検索は問題ないが、部分一致や先頭以外の検索は全文検索やtrigramインデックスを検討。
可能なら大きなバイナリやファイルはオブジェクトストレージ（S3等）に置き、DBには参照パスだけを持たせることでDB負荷を軽減する設計も有効。
実践例（簡単なCREATEとクエリ）
以下は代表的な例（DBMSごとに文法差あり）。
MySQL:
CREATE TABLE articles (id INT PRIMARY KEY, title VARCHAR(255), body TEXT);PostgreSQL:
CREATE TABLE articles (id SERIAL PRIMARY KEY, title VARCHAR(255), body TEXT DEFAULT '');全文検索（PostgreSQL）:
ALTER TABLE articles ADD COLUMN tsv tsvector; UPDATE articles SET tsv = to_tsvector(body); CREATE INDEX idx_tsv ON articles USING GIN(tsv);部分一致（MySQL, prefix index の例）:
CREATE INDEX idx_body_prefix ON articles (body(255));（全文一致や全文検索が必要な場合はFULLTEXTや外部検索を検討）
移行や設計変更の注意
VARCHAR→TEXTやその逆の変更はテーブルのフルコピー/リライトを伴い、ダウンタイムやIO負荷が発生する可能性がある。オンラインDDLをサポートするDBMS/ストレージエンジンの機能を活用する。
検索要件が変わった場合は、テーブル設計だけでなく全文検索インデックスや外部検索サービスの導入検討を行う。
まとめ
「text型」は大きな文字列を扱うための強力な手段ですが、DBMSごとに細かな実装差・制約があるため、それらを理解した上で用途に応じた最適な選択をすることが重要です。短い文字列はVARCHARで明確に制限し、大量テキストはTEXT/CLOB系で扱う・必要に応じて全文検索システムの導入やオブジェクトストレージとの組合せを検討してください。
参考文献
- MySQL 8.0 Reference Manual — BLOB and TEXT Types
- MySQL 8.0 — String Type Overview
- MySQL — Column Default Values（BLOB/TEXTに関する注意）
- PostgreSQL Documentation — Character Types (text, varchar)
- PostgreSQL — TOAST (oversized attribute storage)
- Microsoft Docs — text, ntext, and image (deprecated)
- Microsoft Docs — VARCHAR(MAX) and NVARCHAR(MAX)
- SQLite Documentation — Datatype Affinity
- MySQL — Full-Text Search
- PostgreSQL — Full Text Search
投稿者プロフィール
