Skip navigation links

Additional languages
10.4.4 The ENUM Type »
Section Navigation      [Toggle]

10.4.3. The BLOB and TEXT Types

A BLOB is a binary large object that can hold a variable amount of data. The four BLOB types are TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB. These differ only in the maximum length of the values they can hold. The four TEXT types are TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT. These correspond to the four BLOB types and have the same maximum lengths and storage requirements. See Section 10.5, “Data Type Storage Requirements”.

BLOB columns are treated as binary strings (byte strings). TEXT columns are treated as non-binary strings (character strings). BLOB columns have no character set, and sorting and comparison are based on the numeric values of the bytes in column values. TEXT columns have a character set, and values are sorted and compared based on the collation of the character set.

If strict SQL mode is not enabled and you assign a value to a BLOB or TEXT column that exceeds the column's maximum length, the value is truncated to fit and a warning is generated. For truncation of non-space characters, you can cause an error to occur (rather than a warning) and suppress insertion of the value by using strict SQL mode. See Section 5.1.7, “SQL Modes”.

Beginning with MySQL MySQL 5.1.24, truncation of excess trailing spaces from values to be inserted into TEXT columns always generates a warning, regardless of the SQL mode. (Bug#30059)

If a TEXT column is indexed, index entry comparisons are space-padded at the end. This means that, if the index requires unique values, duplicate-key errors will occur for values that differ only in the number of trailing spaces. For example, if a table contains 'a', an attempt to store 'a ' causes a duplicate-key error. This is not true for BLOB columns.

In most respects, you can regard a BLOB column as a VARBINARY column that can be as large as you like. Similarly, you can regard a TEXT column as a VARCHAR column. BLOB and TEXT differ from VARBINARY and VARCHAR in the following ways:

  • For indexes on BLOB and TEXT columns, you must specify an index prefix length. For CHAR and VARCHAR, a prefix length is optional. See Section 7.4.3, “Column Indexes”.

  • BLOB and TEXT columns cannot have DEFAULT values.

LONG and LONG VARCHAR map to the MEDIUMTEXT data type. This is a compatibility feature. If you use the BINARY attribute with a TEXT data type, the column is assigned the binary collation of the column character set.

MySQL Connector/ODBC defines BLOB values as LONGVARBINARY and TEXT values as LONGVARCHAR.

Because BLOB and TEXT values can be extremely long, you might encounter some constraints in using them:

  • Only the first max_sort_length bytes of the column are used when sorting. The default value of max_sort_length is 1024. This value can be changed using the --max_sort_length=N option when starting the mysqld server. See Section 5.1.3, “System Variables”.

    You can make more bytes significant in sorting or grouping by increasing the value of max_sort_length at runtime. Any client can change the value of its session max_sort_length variable: 

    mysql> SET max_sort_length = 2000;
mysql> SELECT id, comment FROM t
    -> ORDER BY comment;

    Another way to use GROUP BY or ORDER BY on a BLOB or TEXT column containing long values when you want more than max_sort_length bytes to be significant is to convert the column value into a fixed-length object. The standard way to do this is with the SUBSTRING() function. For example, the following statement causes 2000 bytes of the comment column to be taken into account for sorting: 

    mysql> SELECT id, SUBSTRING(comment,1,2000) FROM t
    -> ORDER BY SUBSTRING(comment,1,2000);

  • The maximum size of a BLOB or TEXT object is determined by its type, but the largest value you actually can transmit between the client and server is determined by the amount of available memory and the size of the communications buffers. You can change the message buffer size by changing the value of the max_allowed_packet variable, but you must do so for both the server and your client program. For example, both mysql and mysqldump allow you to change the client-side max_allowed_packet value. See Section 7.5.2, “Tuning Server Parameters”, Section 4.5.1, “mysql — The MySQL Command-Line Tool”, and Section 4.5.4, “mysqldump — A Database Backup Program”. You may also want to compare the packet sizes and the size of the data objects you are storing with the storage requirements, see Section 10.5, “Data Type Storage Requirements”

Each BLOB or TEXT value is represented internally by a separately allocated object. This is in contrast to all other data types, for which storage is allocated once per column when the table is opened.

In some cases, it may be desirable to store binary data such as media files in BLOB or TEXT columns. You may find MySQL's string handling functions useful for working with such data. See Section 11.4, “String Functions”. For security and other reasons, it is usually preferable to do so using application code rather than allowing application users the FILE privilege. You can discuss specifics for various languages and platforms in the MySQL Forums (http://forums.mysql.com/).


User Comments

Posted by Volnei Puttini on June 22 2007 12:04pm[Delete] [Edit]

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 4:36pm[Delete] [Edit]

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 [name withheld] on April 27 2008 11:17am[Delete] [Edit]

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

Add your own comment.