11.4 String Types 字符串类型
11.4.1 The CHAR and VARCHAR Types
11.4.2 The BINARY and VARBINARY Types
11.4.3 The BLOB and TEXT Types
11.4.4 The ENUM Type
11.4.5 The SET Type
字符串类型是 CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM, 和 SET.
这部分描述这些类型如何工作和怎么在你的查询中使用它们。对于存储要求，请看11.8部分的数据类型的存储要求。
--------------------------------------------------------------
11.4.1 The CHAR and VARCHAR Types
The CHAR 和 VARCHAR 类型是相似的, 但它们的存储和查询方法不同。它们的最大长度也不同，尾部空格是否保留也不同。
The CHAR 和 VARCHAR 类型可以存储的长度是你声明中的最大长度，比方说CHAR(30),也就是最大不能唱过30characters.
CHAR列的长度是固定的，也就是你在创建表的时候声明的长度。可用的长度范围是0到255.当CHAR值被存储，它的右边会用空格来填充。当CHAR值被查询，尾部的空格会被移除，除非你开启了PAD_CHAR_TO_FULL_LENGTH 的SQL模式。
在VARCHAR列的值是变长的字符串。可以设置的长度范围是0到65536.一个VARCHAR有效的最大长度和行的最大长度有关(65535bytes是所有列共享的)也和使用的字符集有关。请看c10.4限制表中列的数量和行大小。
对比CHAR, VARCHAR值存储为一个固定的1-byte或2-byte长度的前缀数据。前缀的长度说明了值中byte的多少。如果一列的长度没有超过255bytes则使用1byte长度的前缀。如果超过了255bytes则使用2个字节的长度。
如果没有开启严格的SQL模式，并且你设置了一个超过列最大长度的值在CHAR or VARCHAR 列中，则值被截取来适应并且会产生一个警告。对于截取的不是空格字符，你会得到一个发生的错误(而不是警告)如果你使用的是严格的SQL模式的话。具体请看5.1.8的服务器的SQL模式。
对于 VARCHAR 列，在插入之前超过列长度的尾部空格会被减去并且会产生一个警告。不会考虑使用的SQL模式。对于CHAR列，默认是允许截取尾部的空格的，而不需要考虑SQL模式。
VARCHAR值不会被处理当它们被存储。尾部空格被保留当值被存储和查询时，在标准的SQL中。
下面的表说明了CHAR和VARCHAR的不同。通过将值存储在CHAR(4)和VARCHAR(4)的列来展示不同点(假设列使用单byte字符集例如latin1).
Value CHAR(4) Storage Required VARCHAR(4) Storage Required
'' ' ' 4 bytes '' 1 byte
'ab' 'ab ' 4 bytes 'ab' 3 bytes
'abcd' 'abcd' 4 bytes 'abcd' 5 bytes
'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes
最后一行的数据只有在非严格SQL模式下才会存储，如果MYSQL使用的是严格的SQL模式，则值不会存储，而且会产生一个错误结果。
InnoDB编码固定长度属性大于或等于768bytes的长度作为变长度的属性，它可以跨页存储。例如一个CHAR(255)列可以超过768bytes,如果字符集中的最大字符长度大于3，就好像是utf8mb4那样.
如果给出的一个值存储在CHAR(4) 和 VARCHAR(4)列，查询的值并不总是相同的，因为尾部的空格会被移除掉在CHAR列中。下面的例子说明了这一点的不同:
mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO vc VALUES ('ab ', 'ab ');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
+---------------------+---------------------+
| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
+---------------------+---------------------+
| (ab ) | (ab) |
+---------------------+---------------------+
1 row in set (0.06 sec)
在CHAR 和 VARCHAR列中的值被存储和对比根据列中字符集的排序。
所有MySQL 排序都是PAD SPACE类型的。这也就意味着所有的CHAR, VARCHAR, 和 TEXT值被比较不会考虑任何尾部的空格。 “Comparison” 在这儿不包含模糊匹配的操作, 因为其尾部空格也需要匹配. 例如:
mysql> CREATE TABLE names (myname CHAR(10));
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO names VALUES ('Monty');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT myname = 'Monty', myname = 'Monty ' FROM names;
+------------------+--------------------+
| myname = 'Monty' | myname = 'Monty ' |
+------------------+--------------------+
| 1 | 1 |
+------------------+--------------------+
1 row in set (0.00 sec)
mysql> SELECT myname LIKE 'Monty', myname LIKE 'Monty ' FROM names;
+---------------------+-----------------------+
| myname LIKE 'Monty' | myname LIKE 'Monty ' |
+---------------------+-----------------------+
| 1 | 0 |
+---------------------+-----------------------+
1 row in set (0.00 sec)
这对所有的MYSQL版本都适用，而且不会受服务器SQL模式而影响。
注意：
对于更多MySQL字符集和排序，请看10.1的字符集的支持。对于额外的存储要求，请看11.8的数据类型的存储要求.
对于这种尾部空白字符会被去掉或者忽视的情况，如果一列有一个索引要求唯一值，插入列的值如果只是尾部空格的不同，会导致重复key的错误。例如，如果一个表包含‘a'，试着存储'a '会引发错误。
--------------------------------------------------
11.4.2 The BINARY and VARBINARY Types
The BINARY 和 VARBINARY 数据类型于 CHAR 和 VARCHAR类似, 除了他们是包含二进制字符串而不是非二进制字符串. 也就是说他们存储字节字符串而不是字符字符串。这也意味着他们有二进制字符集和排序，并且存储和比较是基于值的二进制数字。
对于BINARY 和 VARBINARY允许的最大长度是相同的和CHAR 和 VARCHAR类似。只是BINARY 和 VARBINARY的长度是针对byte的长度而不是characters。
BINARY 和 VARBINARY 数据类型不同于CHAR BINARY 和 VARCHAR BINARY数据类型。对于后者的类型，BINARY属性不会使得列被作为二进制字符串列来对待。而且，它会使得列使用二进制比较的字符集。列自身包含非二进制字符的字符串，而不是二进制类型的字节字符串。例如，CHAR(5) BINARY会作为CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin来对待，假设默认的字符集为latin1.这与BINARY(5)不同，它存储5字节的二进制字符串，使用的是binary character set and collation。关于binary strings 和 binary collations for nonbinary strings的不同信息请看10.1.8.5的“The binary Collation Compared to _bin Collations”.
如果没有使用严格的SQL模式，而且你存储一个值在BINARY 或者 VARBINARY列中而且超过了列的最大长度，那么值会被截取并适应然后产生警告。当然如果你开启的是严格模式，则会报错。关于SQL模式，请看5.1.8中的服务器SQL模式。
当BINARY值被存储，它们会添加空白值来达到固定长度。pad value(空白值)是0x00(0byte).在插入过程中添加0x00,在查询时不会截取尾部字节。所有的字节对于比较来说都是重要的，包括ORDER BY 和DISTINCT操作。在比较的过程中0x00bytes和空格不同。0x00<空格。
例如：对一个BINARY(3)列，'a '在插入后变成了'a \0'，'a\0' 变成了 'a\0\0'。当查询的时候插入的值保留不会改变。
对于VARBINARY，在插入的时候不会补全，查询的时候不会截取。所有的字节都是重要的对于比较，包括ORDER BY 和DISTINCT操作。0x00字节和空格在比较中是不同的。0x00空格。
在这种情况下，尾部的pad字节会被去掉或者不计入比较中，如果一个列有索引要求唯一值，只有尾部的pad字节不同会导致重复key错误，比方说，如果表中包含了’a',试着存储'a\0'会引发错误。
如果你计划使用BINARY数据类型来存储二进制数据你需要考虑填充和截取字节。并且你要求查询的值和存储的值完全相等。下面的例子说明了0x00-padding对二进制值比较的影响:
mysql> CREATE TABLE t (c BINARY(3));
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO t SET c = 'a';
Query OK, 1 row affected (0.01 sec)
mysql> SELECT HEX(c), c = 'a', c = 'a\0\0' from t;
+--------+---------+-------------+
| HEX(c) | c = 'a' | c = 'a\0\0' |
+--------+---------+-------------+
| 610000 | 0 | 1 |
+--------+---------+-------------+
1 row in set (0.09 sec)
如果值被查询必须要和存储的一致没有填充的，你也许应该考虑VARBINARY或者BLOB数据类型之一来代替。
--------------------------------------------------
11.4.3 The BLOB and TEXT Types
一个BLOB是一个大的二进制对象，其中可以持有可变数量的数据。四种BLOB类型是 TINYBLOB, BLOB, MEDIUMBLOB, 和 LONGBLOB.他们的不同只是这些值的最大长度不同。四种TEXT类型是TINYTEXT, TEXT, MEDIUMTEXT, 和 LONGTEXT.这对应四种BLOB类型而且有相同的最大长度和存储要求。具体请看11.8中的数据类型的存储要求.
BLOB值按照二进制字符串(byte strings)来对待。他们有二进制字符集和排序，并且比较和存储是基于列中值的字节的数字值。 TEXT 值以非二进制字符串来对待(character strings). 它们有一个字符集而不是二进制，并且值被存储和比较是基于字符集的排序.
如果不是采用严格的SQL模式，你存储一个值超过最大长度的刀BLOB或者TEXT列，值会被截取到适应长度来存储并产生一个警告。如果你采用的是严格模式，而且截取的是非空格字符，那么会产生错误而不是警告。具体的SQL模式请看5.1.8的服务器的SQL模式。
截取超过的尾部空格当值在插入TEXT列的时候总是会产生警告，不管SQL模式。
对于TEXT和BLOB列，没有padding在插入过程中，也没有byte要被截取在查询中。
如果一个TEXT列被索引，索引entry比较在最后是空格加空格。这也就是说，如果索引要求唯一值，那么如果值的不同只有尾部的空格则会报重复key的错误。例如'a'和'a '插入会报错。对于BLOB列不一定会发生。
在大多数情况下，你可以认为BLOB列像VARBINARY列一样大。类似的你可以认为TEXT列和VARCHAR列一样。BLOB和TEXT不同VARBINARY和VARCHAR在如下的方法：
对于索引BLOB 和 TEXT列，你必须定义一个索引的前缀长度。对于CHAR 和 VARCHAR，一个前缀长度是合理的，请看8.3.4的列的索引。
BLOB 和 TEXT 列不能有默认值。
如果您使用带有TEXT数据类型的二进制属性，那么该列就被分配了列字符集的二进制(bin)排序。
LONG 和 LONG VARCHAR 映射到 MEDIUMTEXT数据类型. 这是一个复杂的特性。
MySQL 连接/ODBC 定义 BLOB 值作 LONGVARBINARY，TEXT值作为LONGVARCHAR.
因为BLOB 和 TEXT 值能够十分长，你也许会遇到一些限制在使用它们时：
只有第一个max_sort_length的字节被用于排序。默认长度是1024。你能设置更长的值在服务器启动或运行时。当然任何客户端都可以改变它自己的max_sort_length的大小：
mysql> SET max_sort_length = 2000;
mysql> SELECT id, comment FROM t
-> ORDER BY comment;
在一个查询中处理BLOB或者TEXT列的实例在一个临时表，因为服务器使用在磁盘上的表而不是在内存。因为内存存储引擎不支持这些数据类型(具体看8.4.4，在MySQL中使用内部临时表)。使用磁盘会导致性能下降。所以只有在真的需要的时候才在查询结果中包含BLOB或者TEXT列。例如避免使用SELECT *,来查询所有列。
一个BLOB或者TEXT对象的最大大小是通过他们的类型来决定的。但是你实际上可以传输的最大值在服务器和客户端之间是由可用的缓存大小来决定的。你可以通过变量max_allowed_packet来调整缓存的大小，但是你必须同时在服务器和客户端程序一起修改。例如mysql和mysqldump使你能够改变客户端的max_allowed_packet 的值. 请看5.1.1, “配置服务端”, 4.5.1部分的 “mysql — The MySQL 命令行 工具", 和 4.5.4部分, “mysqldump — 一个数据库备份程序”.你如果想对比包大小和数据对象的大小存储要求，请看11.8部分的数据类型存储要求。
每一个BLOB或者TEXT值是代表
Each BLOB or TEXT 值由一个单独分配的对象在内部表示.这和其他类型的数据不同, 当表打开时，一次分配一列.
在一些情况下，你可能想存储二进制数据例如媒体文件到BLOB或者TEXT列。你可能发现MYSQL的字符串处理函数对这些数据非常有用。具体请看12.5的 “String Functions”. 处于安全和其他原因，通常使用应用程序代码而不是向应用程序用户提供文件特权通常是更好的选择。你能讨论特性通过多种语言和平台在MySQL的论坛。(http://forums.mysql.com/).
11.4.1 The CHAR and VARCHAR Types
11.4.2 The BINARY and VARBINARY Types
11.4.3 The BLOB and TEXT Types
11.4.4 The ENUM Type
11.4.5 The SET Type
字符串类型是 CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM, 和 SET.
这部分描述这些类型如何工作和怎么在你的查询中使用它们。对于存储要求，请看11.8部分的数据类型的存储要求。
--------------------------------------------------------------
11.4.1 The CHAR and VARCHAR Types
The CHAR 和 VARCHAR 类型是相似的, 但它们的存储和查询方法不同。它们的最大长度也不同，尾部空格是否保留也不同。
The CHAR 和 VARCHAR 类型可以存储的长度是你声明中的最大长度，比方说CHAR(30),也就是最大不能唱过30characters.
CHAR列的长度是固定的，也就是你在创建表的时候声明的长度。可用的长度范围是0到255.当CHAR值被存储，它的右边会用空格来填充。当CHAR值被查询，尾部的空格会被移除，除非你开启了PAD_CHAR_TO_FULL_LENGTH 的SQL模式。
在VARCHAR列的值是变长的字符串。可以设置的长度范围是0到65536.一个VARCHAR有效的最大长度和行的最大长度有关(65535bytes是所有列共享的)也和使用的字符集有关。请看c10.4限制表中列的数量和行大小。
对比CHAR, VARCHAR值存储为一个固定的1-byte或2-byte长度的前缀数据。前缀的长度说明了值中byte的多少。如果一列的长度没有超过255bytes则使用1byte长度的前缀。如果超过了255bytes则使用2个字节的长度。
如果没有开启严格的SQL模式，并且你设置了一个超过列最大长度的值在CHAR or VARCHAR 列中，则值被截取来适应并且会产生一个警告。对于截取的不是空格字符，你会得到一个发生的错误(而不是警告)如果你使用的是严格的SQL模式的话。具体请看5.1.8的服务器的SQL模式。
对于 VARCHAR 列，在插入之前超过列长度的尾部空格会被减去并且会产生一个警告。不会考虑使用的SQL模式。对于CHAR列，默认是允许截取尾部的空格的，而不需要考虑SQL模式。
VARCHAR值不会被处理当它们被存储。尾部空格被保留当值被存储和查询时，在标准的SQL中。
下面的表说明了CHAR和VARCHAR的不同。通过将值存储在CHAR(4)和VARCHAR(4)的列来展示不同点(假设列使用单byte字符集例如latin1).
Value CHAR(4) Storage Required VARCHAR(4) Storage Required
'' ' ' 4 bytes '' 1 byte
'ab' 'ab ' 4 bytes 'ab' 3 bytes
'abcd' 'abcd' 4 bytes 'abcd' 5 bytes
'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes
最后一行的数据只有在非严格SQL模式下才会存储，如果MYSQL使用的是严格的SQL模式，则值不会存储，而且会产生一个错误结果。
InnoDB编码固定长度属性大于或等于768bytes的长度作为变长度的属性，它可以跨页存储。例如一个CHAR(255)列可以超过768bytes,如果字符集中的最大字符长度大于3，就好像是utf8mb4那样.
如果给出的一个值存储在CHAR(4) 和 VARCHAR(4)列，查询的值并不总是相同的，因为尾部的空格会被移除掉在CHAR列中。下面的例子说明了这一点的不同:
mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO vc VALUES ('ab ', 'ab ');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
+---------------------+---------------------+
| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
+---------------------+---------------------+
| (ab ) | (ab) |
+---------------------+---------------------+
1 row in set (0.06 sec)
在CHAR 和 VARCHAR列中的值被存储和对比根据列中字符集的排序。
所有MySQL 排序都是PAD SPACE类型的。这也就意味着所有的CHAR, VARCHAR, 和 TEXT值被比较不会考虑任何尾部的空格。 “Comparison” 在这儿不包含模糊匹配的操作, 因为其尾部空格也需要匹配. 例如:
mysql> CREATE TABLE names (myname CHAR(10));
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO names VALUES ('Monty');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT myname = 'Monty', myname = 'Monty ' FROM names;
+------------------+--------------------+
| myname = 'Monty' | myname = 'Monty ' |
+------------------+--------------------+
| 1 | 1 |
+------------------+--------------------+
1 row in set (0.00 sec)
mysql> SELECT myname LIKE 'Monty', myname LIKE 'Monty ' FROM names;
+---------------------+-----------------------+
| myname LIKE 'Monty' | myname LIKE 'Monty ' |
+---------------------+-----------------------+
| 1 | 0 |
+---------------------+-----------------------+
1 row in set (0.00 sec)
这对所有的MYSQL版本都适用，而且不会受服务器SQL模式而影响。
注意：
对于更多MySQL字符集和排序，请看10.1的字符集的支持。对于额外的存储要求，请看11.8的数据类型的存储要求.
对于这种尾部空白字符会被去掉或者忽视的情况，如果一列有一个索引要求唯一值，插入列的值如果只是尾部空格的不同，会导致重复key的错误。例如，如果一个表包含‘a'，试着存储'a '会引发错误。
--------------------------------------------------
11.4.2 The BINARY and VARBINARY Types
The BINARY 和 VARBINARY 数据类型于 CHAR 和 VARCHAR类似, 除了他们是包含二进制字符串而不是非二进制字符串. 也就是说他们存储字节字符串而不是字符字符串。这也意味着他们有二进制字符集和排序，并且存储和比较是基于值的二进制数字。
对于BINARY 和 VARBINARY允许的最大长度是相同的和CHAR 和 VARCHAR类似。只是BINARY 和 VARBINARY的长度是针对byte的长度而不是characters。
BINARY 和 VARBINARY 数据类型不同于CHAR BINARY 和 VARCHAR BINARY数据类型。对于后者的类型，BINARY属性不会使得列被作为二进制字符串列来对待。而且，它会使得列使用二进制比较的字符集。列自身包含非二进制字符的字符串，而不是二进制类型的字节字符串。例如，CHAR(5) BINARY会作为CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin来对待，假设默认的字符集为latin1.这与BINARY(5)不同，它存储5字节的二进制字符串，使用的是binary character set and collation。关于binary strings 和 binary collations for nonbinary strings的不同信息请看10.1.8.5的“The binary Collation Compared to _bin Collations”.
如果没有使用严格的SQL模式，而且你存储一个值在BINARY 或者 VARBINARY列中而且超过了列的最大长度，那么值会被截取并适应然后产生警告。当然如果你开启的是严格模式，则会报错。关于SQL模式，请看5.1.8中的服务器SQL模式。
当BINARY值被存储，它们会添加空白值来达到固定长度。pad value(空白值)是0x00(0byte).在插入过程中添加0x00,在查询时不会截取尾部字节。所有的字节对于比较来说都是重要的，包括ORDER BY 和DISTINCT操作。在比较的过程中0x00bytes和空格不同。0x00<空格。
例如：对一个BINARY(3)列，'a '在插入后变成了'a \0'，'a\0' 变成了 'a\0\0'。当查询的时候插入的值保留不会改变。
对于VARBINARY，在插入的时候不会补全，查询的时候不会截取。所有的字节都是重要的对于比较，包括ORDER BY 和DISTINCT操作。0x00字节和空格在比较中是不同的。0x00空格。
在这种情况下，尾部的pad字节会被去掉或者不计入比较中，如果一个列有索引要求唯一值，只有尾部的pad字节不同会导致重复key错误，比方说，如果表中包含了’a',试着存储'a\0'会引发错误。
如果你计划使用BINARY数据类型来存储二进制数据你需要考虑填充和截取字节。并且你要求查询的值和存储的值完全相等。下面的例子说明了0x00-padding对二进制值比较的影响:
mysql> CREATE TABLE t (c BINARY(3));
Query OK, 0 rows affected (0.01 sec)
mysql> INSERT INTO t SET c = 'a';
Query OK, 1 row affected (0.01 sec)
mysql> SELECT HEX(c), c = 'a', c = 'a\0\0' from t;
+--------+---------+-------------+
| HEX(c) | c = 'a' | c = 'a\0\0' |
+--------+---------+-------------+
| 610000 | 0 | 1 |
+--------+---------+-------------+
1 row in set (0.09 sec)
如果值被查询必须要和存储的一致没有填充的，你也许应该考虑VARBINARY或者BLOB数据类型之一来代替。
--------------------------------------------------
11.4.3 The BLOB and TEXT Types
一个BLOB是一个大的二进制对象，其中可以持有可变数量的数据。四种BLOB类型是 TINYBLOB, BLOB, MEDIUMBLOB, 和 LONGBLOB.他们的不同只是这些值的最大长度不同。四种TEXT类型是TINYTEXT, TEXT, MEDIUMTEXT, 和 LONGTEXT.这对应四种BLOB类型而且有相同的最大长度和存储要求。具体请看11.8中的数据类型的存储要求.
BLOB值按照二进制字符串(byte strings)来对待。他们有二进制字符集和排序，并且比较和存储是基于列中值的字节的数字值。 TEXT 值以非二进制字符串来对待(character strings). 它们有一个字符集而不是二进制，并且值被存储和比较是基于字符集的排序.
如果不是采用严格的SQL模式，你存储一个值超过最大长度的刀BLOB或者TEXT列，值会被截取到适应长度来存储并产生一个警告。如果你采用的是严格模式，而且截取的是非空格字符，那么会产生错误而不是警告。具体的SQL模式请看5.1.8的服务器的SQL模式。
截取超过的尾部空格当值在插入TEXT列的时候总是会产生警告，不管SQL模式。
对于TEXT和BLOB列，没有padding在插入过程中，也没有byte要被截取在查询中。
如果一个TEXT列被索引，索引entry比较在最后是空格加空格。这也就是说，如果索引要求唯一值，那么如果值的不同只有尾部的空格则会报重复key的错误。例如'a'和'a '插入会报错。对于BLOB列不一定会发生。
在大多数情况下，你可以认为BLOB列像VARBINARY列一样大。类似的你可以认为TEXT列和VARCHAR列一样。BLOB和TEXT不同VARBINARY和VARCHAR在如下的方法：
对于索引BLOB 和 TEXT列，你必须定义一个索引的前缀长度。对于CHAR 和 VARCHAR，一个前缀长度是合理的，请看8.3.4的列的索引。
BLOB 和 TEXT 列不能有默认值。
如果您使用带有TEXT数据类型的二进制属性，那么该列就被分配了列字符集的二进制(bin)排序。
LONG 和 LONG VARCHAR 映射到 MEDIUMTEXT数据类型. 这是一个复杂的特性。
MySQL 连接/ODBC 定义 BLOB 值作 LONGVARBINARY，TEXT值作为LONGVARCHAR.
因为BLOB 和 TEXT 值能够十分长，你也许会遇到一些限制在使用它们时：
只有第一个max_sort_length的字节被用于排序。默认长度是1024。你能设置更长的值在服务器启动或运行时。当然任何客户端都可以改变它自己的max_sort_length的大小：
mysql> SET max_sort_length = 2000;
mysql> SELECT id, comment FROM t
-> ORDER BY comment;
在一个查询中处理BLOB或者TEXT列的实例在一个临时表，因为服务器使用在磁盘上的表而不是在内存。因为内存存储引擎不支持这些数据类型(具体看8.4.4，在MySQL中使用内部临时表)。使用磁盘会导致性能下降。所以只有在真的需要的时候才在查询结果中包含BLOB或者TEXT列。例如避免使用SELECT *,来查询所有列。
一个BLOB或者TEXT对象的最大大小是通过他们的类型来决定的。但是你实际上可以传输的最大值在服务器和客户端之间是由可用的缓存大小来决定的。你可以通过变量max_allowed_packet来调整缓存的大小，但是你必须同时在服务器和客户端程序一起修改。例如mysql和mysqldump使你能够改变客户端的max_allowed_packet 的值. 请看5.1.1, “配置服务端”, 4.5.1部分的 “mysql — The MySQL 命令行 工具", 和 4.5.4部分, “mysqldump — 一个数据库备份程序”.你如果想对比包大小和数据对象的大小存储要求，请看11.8部分的数据类型存储要求。
每一个BLOB或者TEXT值是代表
Each BLOB or TEXT 值由一个单独分配的对象在内部表示.这和其他类型的数据不同, 当表打开时，一次分配一列.
在一些情况下，你可能想存储二进制数据例如媒体文件到BLOB或者TEXT列。你可能发现MYSQL的字符串处理函数对这些数据非常有用。具体请看12.5的 “String Functions”. 处于安全和其他原因，通常使用应用程序代码而不是向应用程序用户提供文件特权通常是更好的选择。你能讨论特性通过多种语言和平台在MySQL的论坛。(http://forums.mysql.com/).