MySQL :: MySQL 5.6 リファレンスマニュアル

8.0 English
5.7 English
5.6 English
5.5 English

MySQL 5.6 リファレンスマニュアル / ... / BLOB 型と TEXT 型

11.4.3 BLOB 型と TEXT 型

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

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

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

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

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

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

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

BLOB と TEXT カラムのインデックスには、インデックスプリフィクス長を指定する必要があります。CHAR と VARCHAR では、プリフィクス長はオプションです。セクション8.3.4「カラムインデックス」を参照してください。
BLOB および TEXT カラムに DEFAULT 値を含めることはできません。

BINARY 属性を TEXT データ型と一緒に使用した場合、カラム文字セットのバイナリ照合順序がそのカラムに割り当てられます。

LONG と LONG VARCHAR は MEDIUMTEXT データ型にマップします。これは互換性機能です。

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 変数の値を変更することでメッセージバッファーサイズを変更できますが、サーバーとクライアントプログラムの両方で変更する必要があります。たとえば、mysql と mysqldump のどちらを使用しても、クライアント側の max_allowed_packet 値を変更できます。セクション8.11.2「サーバーパラメータのチューニング」、セクション4.5.1「mysql — MySQL コマンド行ツール」、セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください。パケットサイズおよびソートしているデータオブジェクトのサイズを、ストレージ要件と比較することもできます。セクション11.7「データ型のストレージ要件」を参照してください。

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

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

PREV HOME UP NEXT

User Comments

Posted by Volnei Puttini on June 22, 2007

A pratical example of how write and read images into MySQL tables,
using Trolltech Qt4/C++

This example is for who reads/record images in tables
using fields BLOB.

First: Create a table, for example:
CREATE TABLE picture (
ID INTEGER AUTO_INCREMENT,
IMAGE BLOB,
PRIMARY KEY (ID)
) ENGINE=InnoDB;

2) To read a image to a QByteArray

QString fileName = "IMAGE.JPG";

QImage image(filaName);
LBL_IMAGE->setPixmap(QPixmap::fromImage(image)); // Put image into QLabel object (optional)

// load image to bytearray
QByteArray ba;
QFile f(fileName);
if(f.open(QIODevice::ReadOnly))
{
ba = f.readAll();
f.close();
}

// Writing the image into table
QSqlDatabase::database().transaction();
QSqlQuery query;
query.prepare( "INSERT INTO picture ( IMAGE ) VALUES (:IMAGE)" );
query.bindValue(":IMAGE", ba);
query.exec();
if( query.lastError().isValid()) {
qDebug() << query.lastError().text();
QSqlDatabase::database().rollback();
} else
QSqlDatabase::database().commit();

3) Now, recovery the field with the image

int idx = 1; // The records ID to recover

QSqlDatabase::database().transaction();
QSqlQuery query;
query.prepare("SELECT ID, IMAGE FROM picture WHERE ID=:ID");
query.bindValue(":ID", idx);
query.exec();
query.next();
if( query.lastError().isValid()) {
qDebug() << query.lastError().text();
QSqlDatabase::database().rollback();
} else {
QByteArray ba1 = query.value(1).toByteArray();
QPixmap pic;
pic.loadFromData( ba1);

// Show the image into a QLabel object
LBL_IMAGE->setPixmap(pic);
QSqlDatabase::database().commit();
}

This example works fine and I use it frequently.

Thanks.

Posted by Bryce Nesbitt on April 4, 2008

On MS Windows the "no DEFAULT" rule is an error, while on other platforms it is often a warning. While not a bug, it's possible to get trapped by this if you write code on a lenient platform, and later run it on a strict platform:

mysql> show warnings;

+---------+------+------------------------------------------------------+
| Level   | Code | Message                                              |
+---------+------+------------------------------------------------------+
| Warning | 1101 | BLOB/TEXT column 'abcdef' can't have a default value |
+---------+------+------------------------------------------------------+

Posted by on April 27, 2008

I struggled for some time to utilize mysql's blob column to store images and especially large files with good performance in and out. I found this tutorials implementation very useful: http://www.dreamwerx.net/phpforum/?id=1

Posted by Rajiv Kapoor on December 9, 2008

Following way we can store blob data in a table using MYSQL:
INSERT INTO PICTABLE (MYID, PIC) VALUES (3, LOAD_FILE('/PHP/ME.JPG'));

Posted by Kristian Köhntopp on October 2, 2009

Simon Mudd is right, but there are several things that must come together to make this bad:

1. You must have a query that has an EXPLAIN which includes 'using temporary'. If 'using temporary' is shown in your EXPLAIN plan, then a temporary table is being created either in MEMORY or as MyISAM table on disk. MySQL prefers MEMORY, but there are situations where it is forced to go to disk.

2. You must have a query which includes any TEXT or BLOB type in the column list, that is in the part of the query between SELECT and FROM. The actual size of the column or its content do not matter - even a TINYTEXT that is empty is enough.

Since the MEMORY storage engine cannot represent any TEXT or BLOB types at all, this forces MySQL to realize the table as an on-disk MyISAM table.

How to diagnose:

1. Run show session status:

kris@localhost [test_world]> show session status like 'Created_tmp%tables';

+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 3     |
| Created_tmp_tables      | 7     |
+-------------------------+-------+

2 rows in set (0.00 sec)

2. Execute the query. Make sure it is not cached:

kris@localhost [test_world]> select sql_no_cache * from kris group by countrycode order by population;
...
232 rows in set (0.00 sec)

3. Check show status again:

kris@localhost [test_world]> show session status like 'Created_tmp%tables';

+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 4     |
| Created_tmp_tables      | 8     |
+-------------------------+-------+

2 rows in set (0.00 sec)

As you can see the Created_tmp_tables counter increased by one (in MySQL 5.0 is increases by two because the SHOW STATUS itself creates an in-memory tmp table which is being counted). If the table goes to disk as MyISAM instead of being a MEMORY Table, Created_tmp_disk_tables is also incremented by one, as seen here. This is slow.

The test table I used is using the MySQL world database and

mysql> create table kris as select * from City;
mysql> alter table kris modify column name text;
mysql> alter table kris add primary key (id);

The test query shown above is 'using temporary' because I group by one column and order by another, forcing MySQL to use a temporary table.

Had I been using the same query on the original City table from the world database, a tmp table would have been needed as well, but it would have been created as a MEMORY table as the original name column is a CHAR(35). So Created_tmp_tables is being bumped by one, but Created_tmp_disk_tables is not.

Had I been leaving off the SQL_NO_CACHE, the query cache would have been catching repeated executions of the same query in testing and the counters would not have been moving at all except for the very first test.

Posted by TM Sch on April 21, 2012

This was my first time working with BLOB data, but I first wanted to test WITHOUT an intermediary programming language. (That would add another source of errors, I think.) I had a hard time trying to test inserting and selecting.

Probably this is old had to professional programmers, but my book's limited discussion of BLOB data was about the data type, not how to use it.

Newbies, to make your life easier, here's a quick how-to insert/return blob data at the command line:
****

1) Got errors about NULL value in NOT NULL column. Permissions were fixed as far as I could see (have MySQL installed as a service on Windows 7, and all users had at least read/execute permissions). I did not see any "max_allowed_packet" or "secure_file_priv" already existing in the "my.ini" file.

SOLUTION: In addition to proper permissions, I need to use "/", not "\" in path to blob data (which was a picture). Note, this worked properly even for a non-relative path starting at the drive letter! :D

Meanwhile, I tried moving the photo to a new directory to solve my so-called "permissions" problem, but that wasn't the problem. Truly, I was getting Error 1048 was because I needed to use forward slashes! (You will get Error 1048 if you try to insert a NULL value, or when using LOAD_FILE and it can't read it for any reason...not always permissions.)

2) After solving #1, SELECT statement seemed to confirm the picture is indeed stored in the table. However, this returned so many unreadable characters that I could not scroll back to see the complete results, and I had to wait a couple minutes until my computer stopped beeping. (Lucky for me, the system didn't crash.)

SOLUTION: use the SUBSTRING() function in the SELECT statement to only return so many characters from that blob field!

** SAMPLE DATA IF YOU WANT TO TRY YOURSELF **
** Edited, forgot to use double-backslashes in "Filename" column. **

CREATE TABLE Photos(
PhotoID int unsigned not null auto_increment primary key,
Filename varchar(255) not null unique,
Caption varchar(255) not null,
Photo longblob not null);

DESCRIBE Photos;

INSERT INTO Photos values (
NULL,
'D:\\mytemp\\WOC-logo.jpg',
'Walk of Champions official logo',
LOAD_FILE('D:/mytemp/WOC-logo.jpg')
);

SELECT PhotoID, Filename, Caption, SUBSTRING(Photo,1,20) from Photos;