MySQL 列数据类型(2)

11.3.1. DATETIME、DATE和TIMESTAMP类型

11.3.1.1. 自MySQL 4.1以来的TIMESTAMP属性

DATETIME、DATE和TIMESTAMP类型是相关的。该节描述了它们的特征，它们的类似点和不一样点。

当你须要同时包含日期和时间信息的值时则使用DATETIME类型。MySQL以'YYYY-MM-DD HH:MM:SS'格式检索和显示DATETIME值。支持的范围为'1000-01-01 00:00:00'到'9999-12-31 23:59:59'。(“支持”表示尽管先前的值可能工做，但没有保证)。

当你只须要日期值而不须要时间部分时应使用DATE类型。MySQL用'YYYY-MM-DD'格式检索和显示DATE值。支持的范围是'1000-01-01'到 '9999-12-31'。

TIMESTAMP列类型的属性不固定，取决于MySQL版本和服务器运行的SQL模式。这些属性将在本节后面描述。

可使用任何常见格式指定DATETIME、DATE和TIMESTAMP值：

·         'YYYY-MM-DD HH:MM:SS'或'YY-MM-DD HH:MM:SS'格式的字符串。容许“不严格”语法：任何标点符均可以用作日期部分或时间部分之间的间割符。例如，'98-12-31 11:30:45'、'98.12.31 11+30+45'、'98/12/31 11*30*45'和'98@12@31 11^30^45'是等价的。

·         'YYYY-MM-DD'或'YY-MM-DD'格式的字符串。这里也容许使用“不严格的”语法。例如，'98-12-31'、'98.12.31'、'98/12/31'和'98@12@31'是等价的。

·         'YYYYMMDDHHMMSS'或'YYMMDDHHMMSS'格式的没有间割符的字符串，假定字符串对于日期类型是有意义的。例如，'19970523091528'和'970523091528'被解释为'1997-05-23 09:15:28'，但'971122129015'是不合法的(它有一个没有意义的分钟部分)，将变为'0000-00-00 00:00:00'。

·         'YYYYMMDD'或'YYMMDD'格式的没有间割符的字符串，假定字符串对于日期类型是有意义的。例如，'19970523'和'970523'被解释为 '1997-05-23'，但'971332'是不合法的(它有一个没有意义的月和日部分)，将变为'0000-00-00'。

·         YYYYMMDDHHMMSS或YYMMDDHHMMSS格式的数字，假定数字对于日期类型是有意义的。例如，19830905132800和830905132800被解释为 '1983-09-05 13:28:00'。

·         YYYYMMDD或YYMMDD格式的数字，假定数字对于日期类型是有意义的。例如，19830905和830905被解释为'1983-09-05'。

·         函数返回的结果，其值适合DATETIME、DATE或者TIMESTAMP上下文，例如NOW()或CURRENT_DATE。

无效DATETIME、DATE或者TIMESTAMP值被转换为相应类型的“零”值('0000-00-00 00:00:00'、'0000-00-00'或者00000000000000)。

对于包括日期部分间割符的字符串值，若是日和月的值小于10，不须要指定两位数。'1979-6-9'与'1979-06-09'是相同的。一样，对于包括时间部分间割符的字符串值，若是时、分和秒的值小于10，不须要指定两位数。'1979-10-30 1:2:3'与'1979-10-30 01:02:03'相同。

数字值应为六、八、12或者14位长。若是一个数值是8或14位长，则假定为YYYYMMDD或YYYYMMDDHHMMSS格式，前4位数表示年。若是数字 是6或12位长，则假定为YYMMDD或YYMMDDHHMMSS格式，前2位数表示年。其它数字被解释为仿佛用零填充到了最近的长度。

指定为非限定符字符串的值使用给定的长度进行解释。若是字符串为8或14字符长，前4位数表示年。不然，前2位数表示年。从左向右解释字符串内出现的各部分，以发现年、月、日、小时、分和秒值。这说明不该使用少于6字符的字符串。例如，若是你指定'9903'，认为它表示1999年3月，MySQL将在你的表内插入一个“零”日期值。这是由于年和月值是99和03，但日部分彻底丢失，所以该值不是一个合法的日期。可是，能够明显指定一个零值来表明缺乏的月或日部分。例如，可使用'990300'来插入值'1999-03-00'。

在必定程度上，能够将一个日期类型的值分配给一个不一样的日期类型。可是，值可能会更改或丢失一些信息：

·         若是你为一个DATETIME或TIMESTAMP对象分配一个DATE值，结果值的时间部分被设置为'00:00:00'，由于DATE值未包含时间信息。

·         若是你为一个DATE对象分配一个DATETIME或TIMESTAMP值，结果值的时间部分被删除，由于DATE值未包含时间信息。

·         记住尽管可使用相同的格式指定DATETIME、DATE和TIMESTAMP值，不一样类型的值的范围却不一样。例如，TIMESTAMP值不能早于1970或晚于2037。这说明一个日期，例如'1968-01-01'，虽然对于DATETIME或DATE值是有效的，但对于TIMESTAMP值却无效，若是分配给这样一个对象将被转换为0。

当指定日期值时请注意某些缺陷：

·         指定为字符串的值容许的非严格格式可能会欺骗。例如，值'10:11:12'因为‘:’间割符看上去可能象时间值，但若是用于日期上下文值则被解释为年'2010-11-12'。值'10:45:15'被转换为'0000-00-00'由于'45'不是合法月。

·         在非严格模式，MySQL服务器只对日期的合法性进行基本检查：年、月和日的范围分别是1000到999九、00到12和00到31。任何包含超出这些范围的部分的日期被转换成'0000-00-00'。请注意仍然容许你保存非法日期，例如'2002-04-31'。要想确保不使用严格模式时日期有效，应检查应用程序。

在严格模式，非法日期不被接受，而且不转换。

详细信息参见5.3.2节，“SQL服务器模式”。

·         包含两位年值的日期会使人模糊，由于世纪不知道。MySQL使用如下规则解释两位年值：

o        00-69范围的年值转换为2000-2069。

o        70-99范围的年值转换为1970-1999。

11.3.1.1. 自MySQL 4.1以来的TIMESTAMP属性

注释：在旧版本的MySQL中(4.1以前)，TIMESTAMP列类型的属性在许多方面于本节所描述的大大不一样。若是你须要对旧的TIMESTAMP数据进行转化以便在MySQL 5.1中工做，详情请参见MySQL 4.1 参考手册。

TIMESTAMP列的显示格式与DATETIME列相同。换句话说，显示宽度固定在19字符，而且格式为YYYY-MM-DD HH:MM:SS。

MySQL服务器也能够以MAXDB模式运行。当服务器以该模式运行时，TIMESTAMP与DATETIME相等。也就是说，若是建立表时服务器以MAXDB模式运行，TIMESTAMP列建立为DATETIME列。结果是，该列使用DATETIME显示格式，有相同的值范围，而且没有自动对当前的日期和时间进行初始化或更新。

要想启用MAXDB模式，在启动服务器时使用--sql-mode=MAXDB服务器选项或在运行时经过设置全局sql_mode变量将SQL服务器模式设置为MAXDB：

mysql> SET GLOBAL sql_mode=MAXDB；

客户端能够按照下面方法让服务器为它的链接以MAXDB模式运行：

mysql> SET SESSION sql_mode=MAXDB;

 

MySQL不接受在日或月列包括一个零或包含非法日期值的时间戳值。该规则的惟一例外是特殊值'0000-00-00 00:00:00'。

你能够很是灵便地肯定何时初始化和更新TIMESTAMP和对哪些列进行初始化和更新：

·         你能够将当前的时间戳指定为默认值和自动更新的值。但只能选择一个，或者二者都不选。(不可能一个列选择一个行为而另外一个列选择另外一个行为）。

·         你能够指定哪一个TIMESTAMP列自动初始化或更新为当前的日期和时间。再也不须要为第1个TIMESTAMP列。

请注意下面讨论所信息只适用于建立时未启用MAXDB模式的表的TIMESTAMP列。(如上所述，MAXDB模式使列建立为DATETIME列）。控制TIMESTAMP列的初始化和更新的规则以下所示：

·         若是一个表内的第1个TIMESTAMP列指定为一个DEFAULT值，则不能忽略。 默认值能够为CURRENT_TIMESTAMP或常量日期和时间值。

·         DEFAULT NULL与第1个TIMESTAMP 列的DEFAULT CURRENT_TIMESTAMP相同。对于其它TIMESTAMP列，DEFAULT NULL被视为DEFAULT 0。

·         表内的任何一个TIMESTAMP列能够设置为自动初始化为当前时间戳和/或更新。

·         在CREATE TABLE语句中，能够用下面的任何一种方式声明第1个TIMESTAMP列：

o        用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP子句，列为默认值使用当前的时间戳，而且自动更新。

o        不使用DEFAULT或ON UPDATE子句，与DEFAULT CURRENT_TIMESTAMP ON UPDATECURRENT_TIMESTAMP相同。

o        用DEFAULT CURRENT_TIMESTAMP子句不用ON UPDATE子句，列为默认值使用当前的时间戳可是不自动更新。

o        不用DEFAULT子句但用ON UPDATE CURRENT_TIMESTAMP子句，列有默认值0并自动更新。

o        用常量DEFAULT值，列有给出的 默认值。若是列有一个ON UPDATE CURRENT_TIMESTAMP子句，它自动更新，不然不。

换句话说，你能够为初始值和自动更新的值使用当前的时间戳，或者其中一个使用，或者两个皆不使用。(例如，你能够指定ON UPDATE来启用自动更新而不让列自动初始化）。

·         在DEFAULT和ON UPDATE子句中可使用CURRENT_TIMESTAMP、CURRENT_TIMESTAMP()或者NOW()。它们均具备相同的效果。

两个属性的顺序并不重要。若是一个TIMESTAMP列同时指定了DEFAULT和ON UPDATE，任何一个能够在另外一个的前面。

例子，下面这些语句是等效的：

CREATE TABLE t (ts TIMESTAMP);

CREATE TABLE t (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP

                             ON UPDATE CURRENT_TIMESTAMP);

CREATE TABLE t (ts TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

                             DEFAULT CURRENT_TIMESTAMP);

·         要为TIMESTAMP列而不是第1列指定自动默认或更新，必须经过将第1个TIMESTAMP列显式分配一个常量DEFAULT值来禁用自动初始化和更新。(例如，DEFAULT 0或DEFAULT'2003-01-01 00:00:00')。而后，对于其它TIMESTAMP列，规则与第1个TIMESTAMP列相同，例外状况是不能忽略DEFAULT和ON UPDATE子句。若是这样作，则不会自动进行初始化或更新。

例如：下面这些语句是等效的：

CREATE TABLE t (

    ts1 TIMESTAMP DEFAULT 0,

    ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP

                  ON UPDATE CURRENT_TIMESTAMP);

CREATE TABLE t (

    ts1 TIMESTAMP DEFAULT 0,

    ts2 TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

                  DEFAULT CURRENT_TIMESTAMP);

能够对每一个链接设置当前的时区，相关描述参见5.10.8节，“MySQL服务器时区支持”。TIMESTAMP值以UTC格式保存，存储时对当前的时区进行转换，检索时再转换回当前的时区。只要时区设定值为常量，即可以获得保存时的值。若是保存一个TIMESTAMP值，应更改时区而后检索该值，它与你保存的值不一样。这是由于在两个方向的转换中没有使用相同的时区。当前的时区能够用做time_zone系统变量的值。

能够在TIMESTAMP列的定义中包括NULL属性以容许列包含NULL值。例如：

CREATE TABLE t

(

  ts1 TIMESTAMP NULL DEFAULT NULL,

  ts2 TIMESTAMP NULL DEFAULT 0,

  ts3 TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP

);

若是未指定NULL属性，将列设置为NULL设置则会将它设置为当前的时间戳。请注意容许NULL值的TIMESTAMP列不会采用当前的时间戳，除非要么其 默认值定义为CURRENT_TIMESTAMP，或者NOW()或CURRENT_TIMESTAMP被插入到该列内。换句话说，只有使用以下定义建立，定义为 NULL的TIMESTAMP列才会自动更新：

CREATE TABLE t (ts NULLDEFAULT CURRENT_TIMESTAMP)；

不然-也就是说，若是使用NULL而不是DEFAULT TIMESTAMP来定义TIMESTAMP列，以下所示...

CREATE TABLE t1 (ts NULL DEFAULT NULL);

CREATE TABLE t2 (ts NULL DEFAULT '0000-00-00 00:00:00');

...则必须显式插入一个对应当前日期和时间的值。例如：

INSERT INTO t1 VALUES (NOW());

INSERT INTO t2 VALUES (CURRENT_TIMESTAMP);

11.3.2. TIME类型

MySQL以'HH:MM:SS'格式检索和显示TIME值(或对于大的小时值采用'HHH:MM:SS'格式)。TIME值的范围能够从'-838:59:59'到'838:59:59'。小时部分会所以大的缘由是TIME类型不只能够用于表示一天的时间(必须小于24小时)，还可能为某个事件过去的时间或两个事件之间的时间间隔(能够大于24小时，或者甚至为负)。

你能够用各类格式指定TIME值：

·         'D HH:MM:SS.fraction'格式的字符串。还可使用下面任何一种“非严格”语法：'HH:MM:SS.fraction'、'HH:MM:SS'、'HH:MM'、'D HH:MM:SS'、'D HH:MM'、'D HH'或'SS'。这里D表示日，能够取0到34之间的值。请注意MySQL还不保存分数。

·         'HHMMSS'格式的没有间割符的字符串，假定是有意义的时间。例如，'101112'被理解为'10:11:12'，但'109712'是不合法的(它有一个没有意义的分钟部分)，将变为'00:00:00'。

·         HHMMSS格式的数值，假定是有意义的时间。例如，101112被理解为'10:11:12'。下面格式也能够理解：SS、MMSS、HHMMSS、HHMMSS.fraction。请注意MySQL还不保存分数。

·         函数返回的结果，其值适合TIME上下文，例如CURRENT_TIME。

对于指定为包括时间部分间割符的字符串的TIME值，若是时、分或者秒值小于10，则不须要指定两位数。'8:3:2'与'08:03:02'相同。

为TIME列分配简写值时应注意。没有冒号，MySQL解释值时假定最右边的两位表示秒。(MySQL解释TIME值为过去的时间而不是当天的时间）。例如，你可能认为'1112'和1112表示'11:12:00'(11点过12分)，但MySQL将它们解释为'00:11:12'(11分，12 秒)。一样，'12'和12 被解释为 '00:00:12'。相反，TIME值中使用冒号则确定被看做当天的时间。也就是说，'11:12'表示'11:12:00'，而不是'00:11:12'。

超出TIME范围但合法的值被裁为范围最接近的端点。例如，'-850:00:00'和'850:00:00'被转换为'-838:59:59'和'838:59:59'。

无效TIME值被转换为'00:00:00'。请注意因为'00:00:00'自己是一个合法TIME值，只从表内保存的一个'00:00:00'值还不能说出原来的值是 '00:00:00'仍是不合法的值。

11.3.3. YEAR类型

YEAR类型是一个单字节类型用于表示年。

MySQL以YYYY格式检索和显示YEAR值。范围是1901到2155。

能够指定各类格式的YEAR值：

·         四位字符串，范围为'1901'到'2155'。

·         四位数字，范围为1901到2155。

·         两位字符串，范围为'00'到'99'。'00'到'69'和'70'到'99'范围的值被转换为2000到2069和1970到1999范围的YEAR值。

·         两位整数，范围为1到99。1到69和70到99范围的值被转换为2001到2069和1970到1999范围的YEAR值。请注意两位整数范围与两位字符串范围稍有不一样，由于你不能直接将零指定为数字并将它解释为2000。你必须将它指定为一个字符串'0'或'00'或它被解释为0000。

·         函数返回的结果，其值适合YEAR上下文，例如NOW()。

非法YEAR值被转换为0000。

11.3.4. Y2K事宜和日期类型

MySQL自己对于2000年(Y2K)是安全的(参见1.4.5节，“2000年兼容性”)，但输入给MySQL的值可能不安全。任何包含两位年值的输入都会使人模糊，由于世纪不知道。这些值必须解释为四位形式，由于MySQL内部使用四位来保存年。

对于DATETIME、DATE、TIMESTAMP和YEAR类型，MySQL使用如下规则解释含模糊年值的日期：

·         00-69范围的年值转换为2000-2069。

·         70-99范围的年值转换为1970-1999。

请记住这些规则只是合理猜想数据值表示什么。若是MySQL使用的启发不能产生正确的值，你应提供包含四位年值的确切输入。

ORDER BY能够正确排序有两位年的TIMESTAMP或YEAR值。

部分函数如MIN()和MAX()将TIMESTAMP或YEAR转换为一个数字。这说明使用有两位年值的值，这些函数不能工做正确。在这种状况下的修复方法是将TIMESTAMP或YEAR转换为四位年格式或使用MIN(DATE_ADD(TIMESTAMP,INTERVAL 0 DAYS))。

11.4. String类型

11.4.1. CHAR和VARCHAR类型

11.4.2. BINARY和VARBINARY类型

11.4.3. BLOB和TEXT类型

11.4.4. ENUM类型

11.4.5. SET类型

字符串类型指CHAR、VARCHAR、BINARY、VARBINARY、BLOB、TEXT、ENUM和SET。该节描述了这些类型如何工做以及如何在查询中使用这些类型。

11.4.1. CHAR和VARCHAR类型

CHAR和VARCHAR类型相似，但它们保存和检索的方式不一样。它们的最大长度和是否尾部空格被保留等方面也不一样。在存储或检索过程当中不进行大小写转换。

CHAR和VARCHAR类型声明的长度表示你想要保存的最大字符数。例如，CHAR(30)能够占用30个字符。

CHAR列的长度固定为建立表时声明的长度。长度能够为从0到255的任何值。当保存CHAR值时，在它们的右边填充空格以达到指定的长度。当检索到CHAR值时，尾部的空格被删除掉。在存储或检索过程当中不进行大小写转换。

VARCHAR列中的值为可变长字符串。长度能够指定为0到65,535之间的值。(VARCHAR的最大有效长度由最大行大小和使用的字符集肯定。总体最大长度是65,532字节）。

同CHAR对比，VARCHAR值保存时只保存须要的字符数，另加一个字节来记录长度(若是列声明的长度超过255，则使用两个字节)。

VARCHAR值保存时不进行填充。当值保存和检索时尾部的空格仍保留，符合标准SQL。

若是分配给CHAR或VARCHAR列的值超过列的最大长度，则对值进行裁剪以使其适合。若是被裁掉的字符不是空格，则会产生一条警告。若是裁剪非空格字符，则会形成错误(而不是警告)并经过使用严格SQL模式禁用值的插入。参见5.3.2节，“SQL服务器模式”。

下面的表显示了将各类字符串值保存到CHAR(4)和VARCHAR(4)列后的结果，说明了CHAR和VARCHAR之间的差异：

值

CHAR(4)

存储需求

VARCHAR(4)

存储需求

''

'    '

4个字节

''

1个字节

'ab'

'ab  '

4个字节

'ab '

3个字节

'abcd'

'abcd'

4个字节

'abcd'

5个字节

'abcdefgh'

'abcd'

4个字节

'abcd'

5个字节

请注意上表中最后一行的值只适用不使用严格模式时；若是MySQL运行在严格模式，超过列长度不的值不保存，而且会出现错误。

从CHAR(4)和VARCHAR(4)列检索的值并不老是相同，由于检索时从CHAR列删除了尾部的空格。经过下面的例子说明该差异：

mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));

Query OK, 0 rows affected (0.02 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.00 sec)

根据分配给列的字符集校对规则对CHAR和VARCHAR列中的值进行排序和比较。

请注意全部MySQL校对规则属于PADSPACE类。这说明在MySQL中的全部CHAR和VARCHAR值比较时不须要考虑任何尾部空格。例如：

mysql> CREATE TABLE names (myname CHAR(10), yourname VARCHAR(10));

Query OK, 0 rows affected (0.09 sec)

 

mysql> INSERT INTO names VALUES ('Monty ', 'Monty ');

Query OK, 1 row affected (0.00 sec)

 

mysql> SELECT myname = 'Monty  ', yourname = 'Monty  ' FROM names;

+--------------------+----------------------+

| myname = 'Monty  ' | yourname = 'Monty  ' |

+--------------------+----------------------+

|                  1 |                    1 |

+--------------------+----------------------+

1 row in set (0.00 sec)

请注意全部MySQL版本均如此，而且它不受SQL服务器模式的影响。

对于尾部填充字符被裁剪掉或比较时将它们忽视掉的情形，若是列的索引须要惟一的值，在列内插入一个只是填充字符数不一样的值将会形成复制键值错误。

CHAR BYTE是CHAR BINARY的别名。这是为了保证兼容性。

ASCII属性为CHAR列分配latin1字符集。UNICODE属性分配ucs2字符集。

11.4.2. BINARY和VARBINARY类型

BINARY和VARBINARY类相似于CHAR和VARCHAR，不一样的是它们包含二进制字符串而不要非二进制字符串。也就是说，它们包含字节字符串而不是字符字符串。这说明它们没有字符集，而且排序和比较基于列值字节的数值值。

BINARY和VARBINARY容许的最大长度同样，如同CHAR和VARCHAR，不一样的是BINARY和VARBINARY的长度是字节长度而不是字符长度。

BINARY和VARBINARY数据类型不一样于CHAR BINARY和VARCHAR BINARY数据类型。对于后一种类型，BINARY属性不会将列视为二进制字符串列。相反，它导致使用列字符集的二元 校对规则，而且列自身包含非二进制字符字符串而不是二进制字节字符串。例如CHAR(5) BINARY被视为CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin，假定默认字符集是latin1。这不一样于BINARY(5)，它保存5字节二进制字符串，没有字符集或 校对规则。

当保存BINARY值时，在它们右边填充值以达到指定长度。填充值是0x00(零字节)。插入值时在右侧添加0x00 on，而且选择时不删除尾部的字节。比较时全部字节很重要，包括ORDER BY和DISTINCT操做。比较时0x00字节和空格是不一样的，0x00<空格。

例如：对于一个BINARY(3)列，当插入时 'a' 变为 'a \0'。'a\0'插入时变为'a\0\0'。当选择时两个插入的值均不更改。

对于VARBINARY，插入时不填充字符，选择时不裁剪字节。比较时全部字节很重要，包括ORDER BY和DISTINCT操做。比较时0x00字节和空格是不一样的，0x00<空格。

对于尾部填充字符被裁剪掉或比较时将它们忽视掉的情形，若是列的索引须要惟一的值，在列内插入一个只是填充字符数不一样的值将会形成复制键值错误。

若是你计划使用这些数据类型来保存二进制数据而且须要检索的值与保存的值彻底相同，应考虑前面所述的填充和裁剪特征。下面的例子说明了用0x00填充的BINARY值如何影响列值比较：

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)

若是检索的值必须与指定进行存储而没有填充的值相同，最好使用BLOB数据类型。

建立表时，MySQL能够默默更改BINARY或VARBINARY列的类型。参见13.1.5.1节，“沉寂的列规格变动”。

11.4.3. BLOB和TEXT类型

BLOB是一个二进制大对象，能够容纳可变数量的数据。有4种BLOB类型：TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB。它们只是可容纳值的最大长度不一样。

有4种TEXT类型：TINYTEXT、TEXT、MEDIUMTEXT和LONGTEXT。这些对应4种BLOB类型，有相同的最大长度和存储需求。

参见11.5节，“列类型存储需求”。

BLOB 列被视为二进制字符串(字节字符串)。TEXT列被视为非二进制字符串(字符字符串)。BLOB列没有字符集，而且排序和比较基于列值字节的数值值。TEXT列有一个字符集，而且根据字符集的 校对规则对值进行排序和比较。

在TEXT或BLOB列的存储或检索过程当中，不存在大小写转换。

当未运行在严格模式时，若是你为BLOB或TEXT列分配一个超过该列类型的最大长度的值值，值被截取以保证适合。若是截掉的字符不是空格，将会产生一条警告。使用严格SQL模式，会产生错误，而且值将被拒绝而不是截取并给出警告。参见5.3.2节，“SQL服务器模式”。

在大多数方面，能够将BLOB列视为可以足够大的VARBINARY列。一样，能够将TEXT列视为VARCHAR列。BLOB和TEXT在如下几个方面不一样于VARBINARY和VARCHAR：

·         当保存或检索BLOB和TEXT列的值时不删除尾部空格。(这与VARBINARY和VARCHAR列相同）。

请注意比较时将用空格对TEXT进行扩充以适合比较的对象，正如CHAR和VARCHAR。

·         对于BLOB和TEXT列的索引，必须指定索引前缀的长度。对于CHAR和VARCHAR，前缀长度是可选的。参见7.4.3节，“列索引”。

·         BLOB和TEXT列不能有 默认值。

LONG和LONG VARCHAR对应MEDIUMTEXT数据类型。这是为了保证兼容性。若是TEXT列类型使用BINARY属性，将为列分配列字符集的二元 校对规则。

MySQL链接程序/ODBC将BLOB值定义为LONGVARBINARY，将TEXT值定义为LONGVARCHAR。

因为BLOB和TEXT值可能会很是长，使用它们时可能遇到一些约束：

·         当排序时只使用该列的前max_sort_length个字节。max_sort_length的 默认值是1024；该值能够在启动mysqld服务器时使用--max_sort_length选项进行更改。参见5.3.3节，“服务器系统变量”。

运行时增长max_sort_length的值能够在排序或组合时使更多的字节有意义。任何客户端能够更改其会话max_sort_length变量的值：

mysql> SET max_sort_length = 2000;

mysql> SELECT id, comment FROM tbl_name

    -> ORDER BY comment;

当你想要使超过max_sort_length的字节有意义，对含长值的BLOB或TEXT列使用GROUP BY或ORDER BY的另外一种方式是将列值转换为固定长度的对象。标准方法是使用SUBSTRING函数。例如，下面的语句对comment列的2000个字节进行排序：

mysql> SELECT id, SUBSTRING(comment,1,2000) FROM tbl_name

    -> ORDER BY SUBSTRING(comment,1,2000);

·         BLOB或TEXT对象的最大大小由其类型肯定，但在客户端和服务器之间实际能够传递的最大值由可用内存数量和通讯缓存区大小肯定。你能够经过更改max_allowed_packet变量的值更改消息缓存区的大小，但必须同时修改服务器和客户端程序。例如，可使用 mysql和mysqldump来更改客户端的max_allowed_packet值。参见7.5.2节，“调节服务器参数”、8.3节，“mysql：MySQL命令行工具”和8.8节，“mysqldump：数据库备份程序”。

每一个BLOB或TEXT值分别由内部分配的对象表示。这与其它列类型造成对比，后者是当打开表时为每1列分配存储引擎。

11.4.4. ENUM类型

ENUM是一个字符串对象，其值来自表建立时在列规定中显式枚举的一列值。

在某些状况下，ENUM值也能够为空字符串('')或NULL：

·         若是你将一个非法值插入ENUM(也就是说，容许的值列以外的字符串)，将插入空字符串以做为特殊错误值。该字符串与“普通”空字符串不一样，该字符串有数值值0。后面有详细讨论。

·         若是将ENUM列声明为容许NULL，NULL值则为该列的一个有效值，而且 默认值为NULL。若是ENUM列被声明为NOT NULL，其默认值为容许的值列的第1个元素。

每一个枚举值有一个索引：

·         来自列规定的容许的值列中的值从1开始编号。

·         空字符串错误值的索引值是0。这说明你可使用下面的SELECT语句来找出分配了非法ENUM值的行：

·                mysql> SELECT * FROM tbl_name WHERE enum_col=0;

·         NULL值的索引是NULL。

例如，定义为ENUM的列('one'，'two'，'three')能够有下面所示任何值。还显示了每一个值的索引：

值

索引

NULL

NULL

''

0

'one'

1

'two'

2

'three'

3

枚举最多能够有65,535个元素。

当建立表时，ENUM成员值的尾部空格将自动被删除。

当检索时，保存在ENUM列的值使用列定义中所使用的大小写来显示。请注意能够为ENUM列分配字符集和 校对规则。对于二进制或大小写敏感的校对规则，当为列分配值时应考虑大小写。

若是在数值上下文中检索一个ENUM值，将返回列值的索引。例如，你能够这样从ENUM列搜索数值值：

mysql> SELECT enum_col+0 FROM tbl_name;

若是将一个数字保存到ENUM列，数字被视为索引，而且保存的值是该索引对应的枚举成员。(可是，这不适合LOAD DATA，它将全部输入视为字符串）。不建议使用相似数字的枚举值来定义一个ENUM列，由于这很容易引发混淆。例如，下面的列含有字符串值'0'、'1'和'2'的枚举成员，但数值索引值为一、2和3：

numbers ENUM('0','1','2')

根据枚举成员在列定义中列出的顺序对ENUM值进行排序。(换句话说，ENUM值根据索引编号进行排序）。例如，对于ENUM('a'，'b')，'a'排在'b'前面，但对于ENUM('b'，'a')，'b'排在'a'前面。空字符串排在非空字符串前面，而且NULL值排在全部其它枚举值前面。要想防止意想不到的结果，按字母顺序规定ENUM列。还可使用GROUP BY  CAST(col AS CHAR)或GROUP BY  CONCAT(col)来确保按照词汇对列进行排序而不是用索引数字。

若是你想要肯定一个ENUM列的全部可能的值，使用SHOW COLUMNS FROM tbl_name LIKE enum_col，并解析输出中第2列的ENUM定义。

11.4.5. SET类型

SET是一个字符串对象，能够有零或多个值，其值来自表建立时规定的容许的一列值。指定包括多个SET成员的SET列值时各成员之间用逗号(‘,’)间隔开。这样SET成员值自己不能包含逗号。

例如，指定为SET('one', 'two') NOT NULL的列能够有下面的任何值：

''

'one'

'two'

'one,two'

SET最多能够有64个不一样的成员。

当建立表时，SET成员值的尾部空格将自动被删除。

当检索时，保存在SET列的值使用列定义中所使用的大小写来显示。请注意能够为SET列分配字符集和 校对规则。对于二进制或大小写敏感的校对规则，当为列分配值时应考虑大小写。

MySQL用数字保存SET值，所保存值的低阶位对应第1个SET成员。若是在数值上下文中检索一个SET值，检索的值的位设置对应组成列值的SET成员。例如，你能够这样从一个SET列检索数值值：

mysql> SELECT set_col+0 FROM tbl_name;

若是将一个数字保存到SET列中，数字中二进制表示中的位肯定了列值中的SET成员。对于指定为SET('a','b','c','d')的列，成员有下面的十进制和二进制值：

SET成员

十进制值

二进制值

'a'

1

0001

'b'

2

0010

'c'

4

0100

'd'

8

1000

 

若是你为该列分配一个值9，其二进制形式为1001，所以第1个和第4个SET值成员'a'和'd'被选择，结果值为 'a,d'。

对于包含多个SET元素的值，当插入值时元素所列的顺序并不重要。在值中一个给定的元素列了多少次也不重要。当之后检索该值时，值中的每一个元素出现一次，根据表建立时指定的顺序列出元素。例如，假定某个列指定为SET('a','b','c','d')：

mysql> CREATE TABLE myset (col SET('a', 'b', 'c', 'd'));

插入值'a,d'、'd,a'、'a,d,d'、'a,d,a'和'd,a,d':

mysql> INSERT INTO myset (col) VALUES 

-> ('a,d'), ('d,a'), ('a,d,a'), ('a,d,d'), ('d,a,d');

Query OK, 5 rows affected (0.01 sec)

Records: 5  Duplicates: 0  Warnings: 0

当检索时全部这些值显示为 'a,d'：

mysql> SELECT col FROM myset;

+------+

| col  |

+------+

| a,d  |

| a,d  |

| a,d  |

| a,d  |

| a,d  |

+------+

5 rows in set (0.04 sec)

若是将SET列设置为一个不支持的值，则该值被忽略并发出警告：

mysql> INSERT INTO myset (col) VALUES ('a,d,d,s');

Query OK, 1 row affected, 1 warning (0.03 sec)

 

mysql> SHOW WARNINGS;

+---------+------+------------------------------------------+

| Level   | Code | Message                                  |

+---------+------+------------------------------------------+

| Warning | 1265 | Data truncated for column 'col' at row 1 |

+---------+------+------------------------------------------+

1 row in set (0.04 sec)

 

mysql> SELECT col FROM myset;

+------+

| col  |

+------+

| a,d  |

| a,d  |

| a,d  |

| a,d  |

| a,d  |

| a,d  |

+------+

6 rows in set (0.01 sec)

SET值按数字顺序排序。NULL值排在非NULL SET值的前面。

一般状况，可使用FIND_IN_SET()函数或LIKE操做符搜索SET值：

mysql> SELECT * FROM tbl_name WHERE FIND_IN_SET('value',set_col)>0;

mysql> SELECT * FROM tbl_name WHERE set_col LIKE '%value%';

第1个语句找出SET_col包含value set成员的行。第2个相似，但有所不一样：它在其它地方找出set_col包含value的行，甚至是在另外一个SET成员的子字符串中。

下面的语句也是合法的：

mysql> SELECT * FROM tbl_name WHERE set_col & 1;

mysql> SELECT * FROM tbl_name WHERE set_col = 'val1,val2';

第1个语句寻找包含第1个set成员的值。第2个语句寻找一个确切匹配的值。应注意第2类的比较。将set值与'val1,val2'比较返回的结果与同'val2,val1'比较返回的结果不一样。指定值时的顺序应与在列定义中所列的顺序相同。

若是想要为SET列肯定全部可能的值，使用SHOW COLUMNS FROM tbl_name LIKE set_col并解析输出中第2列的SET定义。

11.5. 列类型存储需求

根据类别列出了MySQL支持的每一个列类型的存储需求。

MyISAM表中行的最大大小为65,534字节。每一个BLOB和TEXT列 帐户只占其中的5至9个字节。

若是MyISAM表包括变长列类型，记录格式也是可变长度。当建立表时，在某些条件下，MySQL能够将一个列从变长类型改成固定长度的类型或反之亦然。详细信息参见13.1.5.1节，“沉寂的列规格变动”。

数值类型存储需求

列类型

存储需求

TINYINT

1个字节

SMALLINT

2个字节

MEDIUMINT

3个字节

INT, INTEGER

4个字节

BIGINT

8个字节

FLOAT(p)

若是0 <= p <= 24为4个字节, 若是25 <= p <= 53为8个字节

FLOAT

4个字节

DOUBLE [PRECISION], item REAL

8个字节

DECIMAL(M,D), NUMERIC(M,D)

变长；参见下面的讨论

BIT(M)

大约(M+7)/8个字节

DECIMAL(和NUMERIC)的存储需求与具体版本有关：

使用二进制格式将9个十进制(基于10)数压缩为4个字节来表示DECIMAL列值。每一个值的整数和分数部分的存储分别肯定。每一个9位数的倍数须要4个字节，而且“剩余的”位须要4个字节的一部分。下表给出了超出位数的存储需求：

剩余的

字节

位数

数目

0

0

1

1

2

1

3

2

4

2

5

3

6

3

7

4

8

4

9

4

日期和时间类型的存储需求

列类型

存储需求

DATE

3个字节

DATETIME

8个字节

TIMESTAMP

4个字节

TIME

3个字节

YEAR

1个字节

字符串类型的存储需求

列类型

存储需求

CHAR(M)

M个字节，0 <= M <= 255

VARCHAR(M)

L+1个字节，其中L <= M 且0 <= M <= 65535(参见下面的注释)

BINARY(M)

M个字节，0 <= M <= 255

VARBINARY(M)

L+1个字节，其中L <= M 且0 <= M <= 255

TINYBLOB, TINYTEXT

L+1个字节，其中L < 28

BLOB, TEXT

L+2个字节，其中L < 216

MEDIUMBLOB, MEDIUMTEXT

L+3个字节，其中L < 224

LONGBLOB, LONGTEXT

L+4个字节，其中L < 232

ENUM('value1','value2',...)

1或2个字节，取决于枚举值的个数(最多65,535个值)

SET('value1','value2',...)

一、二、三、4或者8个字节，取决于set成员的数目(最多64个成员)

VARCHAR、BLOB和TEXT类是变长类型。每一个类型的存储需求取决于列值的实际长度(用前面的表中的L表示)，而不是该类型的最大可能的大小。例如，VARCHAR(10)列能够容纳最大长度为10的字符串。实际存储需求是字符串(L)的长度，加上一个记录字符串长度的字节。对于字符串'abcd'，L是4，存储须要5个字节。

对于CHAR、VARCHAR和TEXT类型，前面的表中的值L和M应解释为字符数目，而且列定义中的这些类型的长度表示字符数目。例如，要想保存一个TINYTEXT值须要L字符+ 1个字节。

要想计算用于保存具体CHAR、VARCHAR或者TEXT列值的字节数，须要考虑该列使用的字符集。在具体状况中，当使用Unicode时，必须记住全部Unicode字符使用相同的字节数。为了细分用于不一样类Unicode字符使用的存储，参见10.5节，“Unicode支持”。

注释：VARCHAR列的有效最大长度为65,532字符。

NDBCLUSTER引擎只支持固定宽度的列。这说明MySQL簇中的表中的VARCHAR列的行为如同类型CHAR(不一样的是每一个记录仍然有一个额外字节空间)。例如，在Cluster表中，声明为VARCHAR(100)的列中的每一个记录存储时将占用101个字节，不管实际存储的记录中的字符串的长度为多少。

BLOB和TEXT类须要 一、二、3或者4个字节来记录列值的长度，取决于该类的最大可能的长度。参见11.4.3节，“BLOB和TEXT类型”。

在NDB Cluster存储引擎中，TEXT和BLOB列的实施是不一样的，其中TEXT列中的每一个记录由两个单独部分组成。一个是固定大小(256字节)，而且实际上保存在原表中。另外一个包括超出256字节的任何数据，保存在隐含的表中。第2个表中的记录老是2,000字节长。这说明若是size<= 256，TEXT列的大小为256(其中size表示记录的大小)；不然，大小是256 +size+(2000–(size–256) 00)。

ENUM对象的大小由不一样的枚举值的数目肯定。枚举用一个字节，能够有255个可能的值。当枚举的值位于256和65,535之间时，用两个字节。参见11.4.4节，“ENUM类型”。

SET对象的大小由不一样的set成员的数量肯定。若是set大小是N，对象占(N+7)/8个字节，四舍五入到一、二、三、4或者8个字节。SET最多能够有64个成员。参见11.4.5节，“SET类型”。

11.6. 选择正确的列类型

为了优化存储，在任何状况下均应使用最精确的类型。例如，若是列的值的范围为从1到99999，若使用整数，则MEDIUMINT UNSIGNED是好的类型。在全部能够表示该列值的类型中，该类型使用的存储最少。

用精度为65位十进制数(基于10)对DECIMAL 列进行全部基本计算(+、-、*、/)。参见11.1.1节，“数值类型概述”。

使用双精度操做对DECIMAL值进行计算。若是准确度不是过重要或若是速度为最高优先级，DOUBLE类型即足够了。为了达到高精度，能够转换到保存在BIGINT中的定点类型。这样能够用64位整数进行全部计算，根据须要将结果转换回浮点值。

11.7. 使用来自其余数据库引擎的列类型

为了使用由其它卖方编写的SQL执行代码，MySQL按照下表所示对列类型进行映射。经过这些映射，能够很容易地从其它数据库引擎将表定义导入到MySQL中：

其它卖方类型

MySQL类型

BOOL,

TINYINT

BOOLEAN

TINYINT

CHAR VARYING(M)

VARCHAR(M)

DEC

DECIMAL

FIXED

DECIMAL

FLOAT4

FLOAT

FLOAT8

DOUBLE

INT1

TINYINT

INT2

SMALLINT

INT3

MEDIUMINT

INT4

INT

INT8

BIGINT

LONG VARBINARY

MEDIUMBLOB

LONG VARCHAR

MEDIUMTEXT

LONG

MEDIUMTEXT

MIDDLEINT

MEDIUMINT

NUMERIC

DECIMAL

在建立表时对列类型进行映射，而后原来的类型定义被丢弃。若是你使用其它卖方的类型建立一个表，而后执行DESCRIBE tbl_name语句，MySQL使用等效的MySQL类型来报告表的结构。例如：

mysql> CREATE TABLE t (a BOOL, b FLOAT8, c LONG, d NUMERIC);

Query OK, 0 rows affected (0.08 sec)

 

mysql> DESCRIBE t;

+-------+---------------+------+-----+---------+-------+

| Field | Type          | Null | Key | Default | Extra |

+-------+---------------+------+-----+---------+-------+

| a     | tinyint(1)    | YES  |     | NULL    |       |

| b     | double        | YES  |     | NULL    |       |

| c     | mediumtext    | YES  |     | NULL    |       |

| d     | decimal(10,0) | YES  |     | NULL    |       |

+-------+---------------+------+-----+---------+-------+

4 rows in set (0.00 sec)

这是MySQL参考手册的翻译版本，关于MySQL参考手册，请访问dev.mysql.com。 原始参考手册为英文版，与英文版参考手册相比，本翻译版可能不是最新的。