MySQLのMEDIUMTEXT徹底解説：容量・性能・運用ベストプラクティス

2025年12月19日 最終更新日時 : 2025年12月19日 エバープレイ編集部

はじめに — MEDIUMTEXTとは何か

MEDIUMTEXTはMySQL/MariaDBが提供するテキスト型の1つで、大量の文字データ（最大およそ16MB）を格納できるカラム型です。長文の記事、ログ、JSONをテキスト形式で格納するケースなどで利用されます。本稿では容量・保存の仕組み・文字セットの影響・インデックスやパフォーマンス上の注意点・運用上のベストプラクティスまで、実務で必要となる観点を技術的に深堀りして解説します。

基本仕様とサイズの定義

MySQLのTEXT系データ型は4段階あり、各型の最大バイト数は次の通りです（バイト数はストレージ上のバイト単位の制限）。

  • TINYTEXT: 2^8 - 1 = 255 バイト
  • TEXT (または TEXT(65535)): 2^16 - 1 = 65,535 バイト（約64KB）
  • MEDIUMTEXT: 2^24 - 1 = 16,777,215 バイト（約16MB）
  • LONGTEXT: 2^32 - 1 = 4,294,967,295 バイト（約4GB）

重要な点は「バイト」単位であることです。文字セットがUTF-8系（utf8mb4）であれば1文字あたり最大4バイトを使うため、格納できる文字数はバイト制限を文字あたりバイト数で割った値よりも少なくなります。

格納とストレージの挙動（InnoDBを中心に）

InnoDBではVARCHARなどの可変長列は通常行内に格納されますが、BLOB/TEXT型は行内にすべてを収められない場合にオーバーフロー領域（オフページ）に格納されます。近年のMySQL（5.6以降）ではROW_FORMATがDYNAMICまたはCOMPRESSEDの場合、先頭の一部（通常最大768バイト程度）が行内に残り、残りは別ページに保存されます。この仕組みにより、1行あたりの固定的なページサイズ（デフォルト16KB）を超えても大きなTEXT/BLOBを扱いやすくなっています。

ただし、オフページ格納は追加のI/Oとポインタ管理（およそ20バイトのオーバーヘッド）が発生します。したがって大きいフィールドへの頻繁なアクセスがあるとパフォーマンスに影響します。

文字セットと長さの誤解を避ける

MEDIUMTEXTの「16,777,215バイト」は文字数ではありません。例えばutf8mb4で最大4バイト/文字を想定すると理論上の最大文字数は約4,194,303文字になりますが、実際の文字数は文字の種類（ASCII, BMP, サロゲートペアなど）によって異なります。文字数上限を意識する場合は、バイト上限と使用する文字セットの最大バイト/文字を考慮してください。

インデックスの制約と対策

TEXT系カラムは全文一致（=）でのインデックス作成ができないため、インデックスを作成する場合はプレフィックス長を指定する必要があります。プレフィックス長は「バイト数」で指定される点にも注意してください。

-- 例: 最初の1000バイトをインデックスにする
CREATE INDEX idx_col_prefix ON t_name (col_name(1000));

utf8mb4環境で文字数を指定する際は、指定したバイト数が実際の文字数に収まるよう余裕を持たせることが重要です。さらに、InnoDBのデフォルトではインデックスキー長の最大が767バイト（古い設定）や3072バイト（innodb_large_prefix有効やバージョン依存）など制限があるため、長いプレフィックスはエラーになる場合があります。

全文検索（FULLTEXT）については、MySQL 5.6以降のInnoDBはFULLTEXTインデックスをサポートしています。大量テキストの検索用途ではFULLTEXTインデックスや外部の全文検索エンジン（Elasticsearch, OpenSearch, Meilisearchなど）の採用を検討してください。

パフォーマンスとI/Oの考え方

  • 読み取り：大きなMEDIUMTEXTをSELECTで頻繁に読み出すとネットワーク帯域とメモリ（クライアント側／サーバ側）を圧迫します。必要な場合はSUBSTRING()で部分のみ取得、あるいは分割して保存する設計も検討しましょう。
  • 書き込み：UPDATEで巨大なTEXTフィールドを上書きすると、その行全体の書き換えやオフページ領域の再配置が発生しやすく、IO負荷が高まることがあります。部分更新はできないため差分保存や外部ストレージを検討します。
  • バイナリデータ：画像・動画・大きなバイナリはBLOB/LONGBLOBにするか、S3などのオブジェクトストレージへ置き、DBには参照（URLなど）を持たせるのが一般的です。DB内にbase64で埋めることは推奨しません。

実務的な使いどころと代替案

MEDIUMTEXTを使うケース：

  • ブログ記事やマークダウン、Eメール本文などの長文テキスト（最大数MB）
  • アプリケーションログの一部や例外のスタックトレース
  • JSONをテキストとして格納する（ただしMySQLのJSON型を優先検討）

代替案：

  • MySQLのJSONデータ型 — JSONを格納・検索・抽出する機能（バイナリ効率化や専用関数）を使いたい場合はこちらが良い。サイズ制限はLONGTEXT級だが内部フォーマットが異なる。
  • 外部オブジェクトストレージ（S3等） — 大きなファイルや多数の大きなテキストを扱う場合、コスト・拡張性・バックアップ面で有利。
  • 全文検索エンジンとの組合せ — 高速な全文検索やスコアリングが必要なら外部検索エンジンの導入を推奨。

DDLと運用例

シンプルなテーブル定義例：

CREATE TABLE articles (
  id INT AUTO_INCREMENT PRIMARY KEY,
  title VARCHAR(255),
  body MEDIUMTEXT,
  created_at DATETIME
) ENGINE=InnoDB;

注意点：

  • 公開APIで大量レスポンスがある場合はbodyを分離したテーブル（article_bodies）に分け、通常の一覧クエリでは結合しないなどの工夫でI/Oを削減できます。
  • バックアップ・レプリケーションにおいて大きなTEXTはバイナリログ量を増やします。binlog_formatやrow/moderateなどの設定を理解した上で運用してください。

移行・リファクタリング時のチェックリスト

  • 現在の最大バイト長を確認する（CHAR_LENGTHとOCTET_LENGTHで文字数とバイト数を把握）。
  • 頻繁に更新されるカラムは外部ストレージまたは別テーブルへ分離。
  • 全文検索をDBで行っている場合、負荷や検索精度を調査し外部エンジン導入を検討。
  • インデックスが必要か、必要ならプレフィックス長を慎重に設定する（文字セット・バイト長を考慮）。
  • バックアップリストア時間、ネットワーク転送量を見積もる。

よくある誤り（Pitfalls）

  • 「文字数＝バイト数」と考えてしまう誤り。マルチバイト文字セットを使う場合は要注意。
  • 大きなTEXTを持つ行を頻繁にUPDATEして性能が低下するケース。差分保存や分離を検討。
  • インデックスせずにLIKE '%keyword%' のような検索を大量のデータで行うと全表スキャンとなる。
  • 大量のTEXTデータをそのままバイナリログに流し続けるとレプリケーションやストレージに負荷がかかる。

運用のベストプラクティス（まとめ）

  • 用途に応じてMEDIUMTEXTかJSON型を選択する（構造化されたJSONはJSON型を優先）。
  • 大きなバイナリやファイルはDBに格納せずオブジェクトストレージを使う。
  • 読み出し効率を考え、頻繁に参照しない大容量カラムは別テーブルに分割する。
  • インデックスは必要最小限かつプレフィックスを慎重に設定し、全文検索要件は専用エンジンで満たす。
  • バックアップ・レプリケーション時のデータ量と再現時間を定期的に評価する。

FAQ：よくある質問

Q. MEDIUMTEXTとLONGTEXT、どちらを選べばいい？

A. ほとんどの場合は必要な最大サイズを基準に選びます。16MBを超える可能性があるならLONGTEXT。ただし必要以上に大きな型を使うと運用面でのコスト（バックアップ・転送）が増えます。

Q. JSONはTEXTでなくJSON型を使うべき？

A. 検索や抽出を頻繁に行うならJSON型（MySQLのネイティブJSON）を使う方が効率的です。単に保存するだけであればTEXTでも構いませんが、可読性や機能面でJSON型に利があります。

参考文献

カテゴリー
IT
前の記事
MEDIUMINT徹底解説：3バイト整数の仕様・利点・注意点と実務での使いどころNew!!
2025年12月19日
次の記事
MySQLのMEDIUMTEXT型を徹底解説：容量・文字数・性能・運用の実務ガイドNew!!
2025年12月19日