Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb
HTML Download (TGZ) - 10.0Mb
HTML Download (Zip) - 10.1Mb


このページは機械翻訳したものです。

11.3.4 BLOB 型と TEXT 型

BLOB はさまざまな容量のデータを保持できる大きなバイナリオブジェクトです。 BLOB 型は、TINYBLOBBLOBMEDIUMBLOB、および LONGBLOB の 4 つがあります。 これらの違いは、保持できる値の最大長だけです。 TEXT 型は、TINYTEXTTEXTMEDIUMTEXT、および LONGTEXT の 4 つがあります。 これらは 4 つの BLOB 型に対応し、最大長とストレージ要件は同じです。 セクション11.7「データ型のストレージ要件」を参照してください。

BLOB 値はバイナリ文字列 (バイトの文字列) として扱われます。 これらには binary 文字セットと照合順序があり、比較とソートはカラム値のバイトの数値に基づきます。 TEXT 値は非バイナリ文字列 (文字の文字列) として扱われます。 これらには binary 以外の文字セットがあり、値は文字セットの照合に基づいてソートおよび比較されます。

厳密な SQL モードが有効でない場合に、BLOB または TEXT カラムにその最大長を超える値を割り当てると、その値はカラムの最大長に合わせて切り捨てられ、警告メッセージが表示されます。 スペース以外の文字の切り捨てに関しては、厳密な SQL モードを使用することで、警告ではなくエラーを発生させて、その値の挿入を抑制できます。 セクション5.1.11「サーバー SQL モード」を参照してください。

TEXT カラムに挿入される値から、超過した末尾のスペースを切り捨てると、SQL モードには関係なく、常に警告が生成されます。

TEXT および BLOB カラムでは、挿入時にパディングは行われず、選択時にバイトは削除されません。

TEXT カラムにインデックスが設定されている場合、インデックスエントリの比較では末尾がスペースで埋められます。 つまり、インデックスに一意の値が必要な場合は、末尾のスペースの数のみが異なる値に対して重複キーエラーが発生します。 たとえば、テーブルに 'a' が含まれている場合、'a ' を格納しようとすると、重複キーエラーが発生します。 これは BLOB カラムには当てはまりません。

ほとんどの点で、BLOB カラムを、任意の長さに設定できる VARBINARY カラムと見なすことができます。 同様に、TEXT カラムを VARCHAR カラムと見なすことができます。 BLOBTEXT は、次の点で VARBINARYVARCHAR とは異なっています。

  • BLOBTEXT カラムのインデックスには、インデックスプリフィクス長を指定する必要があります。 CHARVARCHAR では、プリフィクス長はオプションです。 セクション8.3.5「カラムインデックス」を参照してください。

  • BLOB および TEXT カラムに DEFAULT 値を含めることはできません。

BINARY 属性を TEXT データ型とともに使用する場合、カラムにはカラム文字セットのバイナリ (_bin) 照合順序が割り当てられます。

LONGLONG VARCHARMEDIUMTEXT データ型にマップします。 これは互換性機能です。

MySQL Connector/ODBC は BLOB 値を LONGVARBINARY として、TEXT 値を LONGVARCHAR として定義します。

BLOB 値と TEXT 値は非常に長くなる可能性があるので、使用するときに次の制約が生じることがあります。

  • ソート時には、カラムの max_sort_length バイトだけが使用されます。 max_sort_length のデフォルト値は 1024 です。 サーバーの起動時または実行時に、max_sort_length の値を増やすことによって、ソートまたはグループ化に影響するバイトを増やすことができます。 すべてのクライアントで max_sort_length セッション変数の値を変更できます。

    mysql> SET max_sort_length = 2000;
    mysql> SELECT id, comment FROM t
        -> ORDER BY comment;
  • 一時テーブルを使用して処理されるクエリーの結果に BLOB カラムまたは TEXT カラムのインスタンスがあると、MEMORY ストレージエンジンがこれらのデータ型をサポートしていないので、サーバーはメモリー内ではなくディスク上でテーブルを使用します (セクション8.4.4「MySQL での内部一時テーブルの使用」を参照してください)。 ディスクの使用はパフォーマンスの低下を伴うので、クエリーの結果に BLOB カラムまたは TEXT カラムを含めるのは必要な場合に限定してください。 たとえば、SELECT * はすべてのカラムを選択するので使用しないでください。

  • BLOB または TEXT オブジェクトの最大サイズはその型で決まりますが、クライアントとサーバー間で実際に送信できる最大値は、使用可能なメモリーの容量と通信バッファーのサイズで決まります。 max_allowed_packet 変数の値を変更することでメッセージバッファーサイズを変更できますが、サーバーとクライアントプログラムの両方で変更する必要があります。 たとえば、mysqlmysqldump のどちらを使用しても、クライアント側の max_allowed_packet 値を変更できます。 セクション5.1.1「サーバーの構成」セクション4.5.1「mysql — MySQL コマンドラインクライアント」、およびセクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。 パケットサイズおよびソートしているデータオブジェクトのサイズを、ストレージ要件と比較することもできます。セクション11.7「データ型のストレージ要件」を参照してください。

BLOB 値または TEXT 値はそれぞれ、別々に割り当てられたオブジェクトによって内部的に表現されます。 これは、テーブルが開かれるときにカラムごとに一度ストレージが割り当てられる、ほかのすべてのデータ型と対照的です。

メディアファイルなどのバイナリデータを BLOB または TEXT カラムに格納するほうがよい場合もあります。 このようなデータの処理には、MySQL の文字列操作関数が役立つことがあります。 セクション12.8「文字列関数および演算子」を参照してください。 セキュリティーなどの理由のために、通常は、アプリケーションユーザーに FILE 権限を与えるのではなく、アプリケーションコードを使用して実行することをお勧めします。 MySQL フォーラム (http://forums.mysql.com/) では、さまざまな言語やプラットフォームの詳細について話し合うことができます。