06-2.html

MySQL4.1.0 中文参考手册

<LI>
如果将一个 <CODE>DATETIME</CODE> 或 <CODE>TIMESTAMP</CODE> 值赋给一个 <CODE>DATE</CODE> 对象，结果值的时间部分被删除，因为 <CODE>DATE</CODE> 类型不能存储时间信息。

<LI>

记住，尽管 <CODE>DATETIME</CODE>、<CODE>DATE</CODE> 和 <CODE>TIMESTAMP</CODE> 值全都可以用同样的格式集来指定，但所有类型不都有同有同样的值范围。例如，<CODE>TIMESTAMP</CODE> 值不能早于 <CODE>1970</CODE> 或晚于 <CODE>2037</CODE>。这就意味着，一个日期例如 <CODE>'1968-01-01'</CODE>，作为一个 <CODE>DATETIME</CODE> 或 <CODE>DATE</CODE> 值是合法的，但不是一个有效的 <CODE>TIMESTAMP</CODE> 值，当它被赋于一个这样的对象时，它将被转换为  <CODE>0</CODE>。
</UL>

<P>
<A NAME="IDX1071"></A>
<A NAME="IDX1072"></A>
当指定日期值时，当心某些失误：
</P>

<UL>
<LI>
你可能会被以字符串指定值时所允许的宽松格式欺骗。例如，一个值如 <CODE>'10:11:12'</CODE> 的，因为分界符 <SAMP>“:”</SAMP> 可能看起来像是一个时间值， 但是当它被用于一个日期语境中时，它将被解释成为  <CODE>'2010-11-12'</CODE> 年。而值 <CODE>'10:45:15'</CODE> 将被转换成 <CODE>'0000-00-00'</CODE>，因为 <CODE>'45'</CODE> 是一个不合法的月份。

<LI>
MySQL 服务器仅对日期的有效性执行基本的检验：天为 <CODE>00-31</CODE>，月为 <CODE>00-12</CODE>，年为 <CODE>1000-9999</CODE>。任何不是这个范围内的日期将被转换为 <CODE>0000-00-00</CODE>。请注意，这仍然允许你存储一个无效的日期例如<CODE>2002-04-31</CODE>。它允许一个 WEB 应用程序不进行进一步的检查而存储一个表单中的数据。为了确保一个日期值的有效性，在你的应用程序里执行有效性检查。

<LI>
以两位数字指定年份是存在二义性的，因为世纪是未知的。MySQL 以下面的规则解释一个 2 位年份值：

<UL>
<LI>

<CODE>00-69</CODE> 范围的年份值被转换为 <CODE>2000-2069</CODE>。

<LI>

<CODE>70-99</CODE> 范围的年份值被转换为 <CODE>1970-1999</CODE>。
</UL>

</UL>



<H4><A NAME="TIME"></A>6.2.2.3  <CODE>TIME</CODE> 类型</H4>

<P>
<A NAME="IDX1073"></A>

</P>
<P>
MySQL 以 <CODE>'HH:MM:SS'</CODE> 格式(或对大的小时值时使用 <CODE>'HHH:MM:SS'</CODE> 格式)检索和显示 <CODE>TIME</CODE> 值。<CODE>TIME</CODE> 值的范围可以从 <CODE>'-838:59:59'</CODE> 到 <CODE>'838:59:59'</CODE>。小时部分可以这么大的原因 是，<CODE>TIME</CODE> 类型不仅可以用于表示一天的时间(这一定不会超过 24 小时)，而且可以用来表示所经过的时间或两个事件之间的时间间隔(这可能比 24 小时大许多或是一个负值)。
</P>

<P>
<CODE>TIME</CODE> 值可以多种格式指定：
</P>

<UL>
<LI>
一个 <CODE>'D HH:MM:SS.fraction'</CODE> 格式的字符串。(注意，MySQL 仍然不能为时间列存储毫秒“fraction”)下面所示的任一种“宽松”的语法均可以被使用：<CODE>HH:MM:SS.fraction</CODE>、<CODE>HH:MM:SS</CODE>、<CODE>HH:MM</CODE>、<CODE>D HH:MM:SS</CODE>、<CODE>D HH:MM</CODE>、<CODE>D HH</CODE> 或 <CODE>SS</CODE>。这里的 <CODE>D</CODE> 是一个在 0-33 之间的日期。

<LI>
一个无定界符的 <CODE>'HHMMSS'</CODE> 格式的字符串，只要字符串看起来像是一个时间。例如：<CODE>'101112'</CODE> 可被理解为 <CODE>'10:11:12'</CODE>，但是 <CODE>'109712'</CODE> 是不合法的(它有一个无意义的分钟部分)，当被插入时会转换为 <CODE>'00:00:00'</CODE>。

<LI>
一个 <CODE>HHMMSS</CODE> 格式的数字，只要数字看起来像一个时间。例如，<CODE>101112</CODE> 可被理解为 <CODE>'10:11:12'</CODE>。下面的任一格式均可被正常理解：<CODE>SS</CODE>、<CODE>MMSS</CODE>、<CODE>HHMMSS</CODE>、<CODE>HHMMSS.fraction</CODE>。注意，MySQL 仍不能保存 毫秒(fraction)部分。

<LI>
在一个 <CODE>TIME</CODE> 语境中，函数(例如 <CODE>CURRENT_TIME</CODE>)的返回值将会返一个合理的格式。
</UL>

<P>
对于以字符串指定的包含时间定界符的 <CODE>TIME</CODE> 值，不必要为小于 <CODE>10</CODE> 的时、分或秒指定 2 位数字。<CODE>'8:3:2'</CODE> 与 <CODE>'08:03:02'</CODE> 是一致的。
</P>

<P>
将“短”的 <CODE>TIME</CODE> 值赋给另一个 <CODE>TIME</CODE> 列时要格外小心。如果没有冒号，MySQL 使用最右位代表秒的假设来解释值。(MySQL 将 <CODE>TIME</CODE> 值解释为经过的时间，而不是时刻)。例如，你可能会认为 <CODE>'1112'</CODE> and <CODE>1112</CODE> 的意思就是 <CODE>'11:12:00'</CODE> (11 点过 12 分)，但是 MySQL 却将它解释为 <CODE>'00:11:12'</CODE> (11 分，12 秒)。同样的，<CODE>'12'</CODE> 和 <CODE>12</CODE> 被解释为 <CODE>'00:00:12'</CODE>。有冒号的 <CODE>TIME</CODE> 值，由于冒号的存在，通常认为是处理过的时刻。这就是说，<CODE>'11:12'</CODE> 就意味着是 <CODE>'11:12:00'</CODE>，而不是 <CODE>'00:11:12'</CODE>。
</P>
<P>
如果值超出了 <CODE>TIME</CODE> 的范围，但是其它分、秒部分是合法的，它将被剪切到取值范围的适当端点。例如，<CODE>'-850:00:00'</CODE> 和 <CODE>'850:00:00'</CODE> 将被分别转换为 <CODE>'-838:59:59'</CODE> 和 <CODE>'838:59:59'</CODE>。
</P>

<P>
不合法的 <CODE>TIME</CODE> 值将被转换为 <CODE>'00:00:00'</CODE>。注意，因为 <CODE>'00:00:00'</CODE> 自身是一个合法的 <CODE>TIME</CODE> 值，这就没有办法区分，存储在一个表中的 <CODE>'00:00:00'</CODE>，原来的值是否就是指定为 <CODE>'00:00:00'</CODE> 或是一个不合法的值。
</P>



<H4><A NAME="YEAR"></A>6.2.2.4  <CODE>YEAR</CODE> 类型</H4>

<P>
<A NAME="IDX1074"></A>

</P>
<P>
<CODE>YEAR</CODE> 类型是一个以 1 个字节描述年份的类型。
</P>

<P>
MySQL 以 <CODE>YYYY</CODE> 格式检索和显示一个 <CODE>YEAR</CODE> 值。范围是 <CODE>1901</CODE> 到 <CODE>2155</CODE>。
</P>

<P>
可以以多个格式指定 <CODE>YEAR</CODE> 值：
</P>

<UL>
<LI>
一个在 <CODE>'1901'</CODE> 到 <CODE>'2155'</CODE> 范围之内的 4 位字符串。

<LI>
一个在 <CODE>1901</CODE> 到 <CODE>2155</CODE> 范围之内的 4 位数字。

<LI>
一个在 <CODE>'00'</CODE> 到 <CODE>'99'</CODE> 范围之内的 2 位字符串。<CODE>'00'</CODE> 到 <CODE>'69'</CODE> 和 <CODE>'70'</CODE> 到 <CODE>'99'</CODE> 范围内的值将被分别转换到 <CODE>2000</CODE> 到 <CODE>2069</CODE> 和 <CODE>1970</CODE> 到 <CODE>1999</CODE> 范围内的 <CODE>YEAR</CODE> 值。

<LI>
一个在 <CODE>1</CODE> 到 <CODE>99</CODE> 范围之内的数字。<CODE>1</CODE> 到 <CODE>69</CODE> 和 <CODE>70</CODE> 到 <CODE>99</CODE> 范围内的值将被分别转换到 <CODE>2001</CODE> 到 <CODE>2069</CODE> 和 <CODE>1970</CODE> 到 <CODE>1999</CODE> 范围内的 <CODE>YEAR</CODE> 值。注意，两位数字的范围与两位字符串的范围稍稍有点不同，因为你不能直接地以数字指定一个零值，将它解释为 <CODE>2000</CODE>。你<STRONG>必须</STRONG> 以一个 <CODE>'0'</CODE> 或 <CODE>'00'</CODE> 格式的字符串指定它，否则它将被解释为 <CODE>0000</CODE>。

<LI>
在一个 <CODE>YEAR</CODE> 的语境中，函数(例如 <CODE>NOW()</CODE>)的返回值将会返回一个合理的格式。
</UL>

<P>
不合法的 <CODE>YEAR</CODE> 值将被转换为 <CODE>0000</CODE>。
</P>



<H3><A NAME="String_types"></A>6.2.3  字符串类型</H3>

<P>
<A NAME="IDX1075"></A>
<A NAME="IDX1076"></A>

</P>
<P>
<A NAME="IDX1077"></A>
<A NAME="IDX1078"></A>

</P>

<P>
字符串类型有 <CODE>CHAR</CODE>、<CODE>VARCHAR</CODE>、<CODE>BLOB</CODE>、<CODE>TEXT</CODE>、<CODE>ENUM</CODE> 和 <CODE>SET</CODE>。这个章节描述这些类型是如何工作的，它们的存储需求，以及在你的查询中如何使用它们。
</P>

<TABLE BORDER WIDTH="100%">
<TR><TD><STRONG>类型 </STRONG> </TD><TD> <STRONG>最大尺寸 </STRONG> </TD><TD> <STRONG>字节 </STRONG>
</TD></TR>
<TR><TD><CODE>TINYTEXT</CODE> 或 <CODE>TINYBLOB</CODE> </TD><TD> 2^8-1 </TD><TD> 255
</TD></TR>
<TR><TD><CODE>TEXT</CODE> 或 <CODE>BLOB</CODE> </TD><TD> 2^16-1 (64K-1) </TD><TD> 65535
</TD></TR>
<TR><TD><CODE>MEDIUMTEXT</CODE> 或 <CODE>MEDIUMBLOB</CODE> </TD><TD> 2^24-1 (16M-1) </TD><TD> 16777215
</TD></TR>
<TR><TD><CODE>LONGBLOB</CODE> </TD><TD> 2^32-1 (4G-1) </TD><TD> 4294967295
</TD></TR>
</TABLE>



<H4><A NAME="CHAR"></A>6.2.3.1  <CODE>CHAR</CODE> 和 <CODE>VARCHAR</CODE> 类型</H4>

<P>
<CODE>CHAR</CODE> 和 <CODE>VARCHAR</CODE> 类型是很相似的，但是它们被存储与检索的方式有些不同。
</P>

<P>
一个 <CODE>CHAR</CODE> 列的长度被固定为你创建表进所声明的长度。长度可以是 1 和 255 之间的任一值。(从 MySQL 3.23 之后，<CODE>CHAR</CODE> 的长度可以是 0 到 255。)当 <CODE>CHAR</CODE> 值被存储时，他们被用空格在右边填补到指定长度。当 <CODE>CHAR</CODE> 值被检索时，尾部的空格被截除。
</P>

<P>
<CODE>VARCHAR</CODE> 列的值是变长的字符串。你可以声明一个 <CODE>VARCHAR</CODE> 列在  1 到 255, 就像对 <CODE>CHAR</CODE> 列一样。然而，与 <CODE>CHAR</CODE> 相反的，<CODE>VARCHAR</CODE> 值只以所需的字符数存储，另加一个字节存储记录的长度。值并不被填补；相反的，当被存储时，尾部的空格被截除。(这个截除空格方式不同于 ANSI SQL 规约。)
</P>

<P>
如果将一个超过列最大长度的值赋给一个 <CODE>CHAR</CODE> 或 <CODE>VARCHAR</CODE> 列，该值将截断以适合它。
</P>

<P>
下表通过在 <CODE>CHAR(4)</CODE> 和 <CODE>VARCHAR(4)</CODE> 列中存储不同的字符串的结果显示了两种类型列的不同：
</P>

<TABLE BORDER WIDTH="100%">
<TR><TD><STRONG>值 </STRONG> </TD><TD> <CODE>CHAR(4)</CODE> </TD><TD> <STRONG>存储需求 </STRONG> </TD><TD> <CODE>VARCHAR(4)</CODE> </TD><TD> <STRONG>存储需求 </STRONG>
</TD></TR>
<TR><TD><CODE>''</CODE> </TD><TD> <CODE>'    '</CODE> </TD><TD> 4 字节 </TD><TD> <CODE>''</CODE> </TD><TD> 1 字节
</TD></TR>
<TR><TD><CODE>'ab'</CODE> </TD><TD> <CODE>'ab  '</CODE> </TD><TD> 4 字节 </TD><TD> <CODE>'ab'</CODE> </TD><TD> 3 字节
</TD></TR>
<TR><TD><CODE>'abcd'</CODE> </TD><TD> <CODE>'abcd'</CODE> </TD><TD> 4 字节 </TD><TD> <CODE>'abcd'</CODE> </TD><TD> 5 字节
</TD></TR>
<TR><TD><CODE>'abcdefgh'</CODE> </TD><TD> <CODE>'abcd'</CODE> </TD><TD> 4 字节 </TD><TD> <CODE>'abcd'</CODE> </TD><TD> 5 字节
</TD></TR>
</TABLE>

<P>
在各种情况下，<CODE>CHAR(4)</CODE> 和 <CODE>VARCHAR(4)</CODE> 列的检索值均是一样的，因为在 <CODE>CHAR</CODE> 列上检索值的尾部空格会被截除。
</P>

<P>
<CODE>CHAR</CODE> 和 <CODE>VARCHAR</CODE> 列值以省略字母大小写的方式进行排序和比较，除非在表建立时 <CODE>BINARY</CODE> 属性被指定。<CODE>BINARY</CODE> 属性意味着，该列值根据 MySQL 服务器正在运行的机器的 ASCII 表顺序进行字母大小写敏感的方式排序和比较。<CODE>BINARY</CODE> 并不影响该列如何被存储和检索。
</P>

<P>
<CODE>BINARY</CODE> 属性是有粘性的。这就意味着，如果一个被标记为 <CODE>BINARY</CODE> 的列被用于一个表达式中，整个表达式将作为一个 <CODE>BINARY</CODE> 值被比较。
</P>

<P>
在表创建时，MySQL 可能会隐式地改变一个 <CODE>CHAR</CODE> 或 <CODE>VARCHAR</CODE> 列的类型。查看章节 <A HREF="06-5.html#Silent_column_changes">6.5.3.1  隐式的列定义变化</A>。
</P>



<H4><A NAME="BLOB"></A>6.2.3.2  <CODE>BLOB</CODE> 和 <CODE>TEXT</CODE> 类型</H4>

<P>
<A NAME="IDX1079"></A>
<A NAME="IDX1080"></A>

</P>
<P>
一个 <CODE>BLOB</CODE> 是一个可以保存一可变数量的数据的二进制大对象。四个 <CODE>BLOB</CODE> 类型(<CODE>TINYBLOB</CODE>、<CODE>BLOB</CODE>、<CODE>MEDIUMBLOB</CODE> 和 <CODE>LONGBLOB</CODE>)之间的不同仅仅在于他们能保存值的最大长度不一致。查看章节 <A HREF="06-2.html#Storage_requirements">6.2.6  列类型存储需求</A>。
</P>
<P>
四个 <CODE>TEXT</CODE> 类型(<CODE>TINYTEXT</CODE>、<CODE>TEXT</CODE>、<CODE>MEDIUMTEXT</CODE> 和 <CODE>LONGTEXT</CODE>)对应与四个 <CODE>BLOB</CODE> 类型，并且有相同的最大长度和存储需求。在 <CODE>BLOB</CODE> 和 <CODE>TEXT</CODE> 类型之间的唯一差别就是，对 <CODE>BLOB</CODE> 值是以字母大小写敏感的方式进行排序和比较的，而对 <CODE>TEXT</CODE> 值以忽略字母大小写方式进行排序和比较。换句话说，<CODE>TEXT</CODE> 是一个忽略字母大小写的 <CODE>BLOB</CODE>。
</P>

<P>
如果将一个超过列类型最大长度的值赋给一个 <CODE>BLOB</CODE> 或 <CODE>TEXT</CODE> 列，该值将被截断以适应它。
</P>

<P>
在大多数方面，可以将一个 <CODE>TEXT</CODE> 列看作是一个你所希望大 <CODE>VARCHAR</CODE> 列。同样的，<CODE>BLOB</CODE> 列可以看作是一个 <CODE>VARCHAR BINARY</CODE> 列。差别就在于：
</P>

<UL>
<LI>
在 MySQL 3.23.2 和更新的版本中，可以在 <CODE>BLOB</CODE> 和 <CODE>TEXT</CODE> 列上建立索引。而较老版本的 MySQL 是不支持的。

<LI>
当 <CODE>BLOB</CODE> and <CODE>TEXT</CODE> 列值被存储时，尾部的空格不会被剪切，这与 <CODE>VARCHAR</CODE> 列是不一样的。

<LI>
<A NAME="IDX1081"></A>
<A NAME="IDX1082"></A>
<A NAME="IDX1083">