示例(译者注)：

* 接上例结果
# 下列示例结果与上述结果相悖
mysql> ALTER TABLE `ta` CHANGE `date1` `date1` TIMESTAMP(4);
Query OK, 3 rows affected (0.02 sec)
Records: 3  Duplicates: 0  Warnings: 0
mysql> SELECT * FROM `tA`;
+----+-------+
| id | date1 |
+----+-------+
|  1 |  0305 |
|  2 |  0003 |
|  3 |  0000 |
+----+-------+
3 rows in set (0.01 sec)
mysql> SELECT HOUR(`date1`) FROM `tA`;
+---------------+
| Hour(`date1`) |
+---------------+
|            15 |
|             0 |
|          NULL |
+---------------+
3 rows in set (0.02 sec)
mysql> SELECT SECOND(`date1`) FROM `tA`;
+-----------------+
| second(`date1`) |
+-----------------+
|              42 |
|               0 |
|            NULL |
+-----------------+
3 rows in set (0.01 sec)
* 以上结果在 MySQL 4.0.12 中测试

在某种程序上，你可以将一个日期值赋给另一种日期类型的对象。然而，这可能会使值产生改变或丢失一部分信息。

• 如果将一个 DATE 值赋给一个 DATETIME 或 TIMESTAMP 对象，结果值的时间部分将被设为 ''''00:00:00''''，因为 DATE 值不包含时间信息。
• 如果将一个 DATETIME 或 TIMESTAMP 值赋给一个 DATE 对象，结果值的时间部分被删除，因为 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 服务器仅对日期的有效性执行基本的检验：天为 00-31，月为 00-12，年为 1000-9999。任何不是这个范围内的日期将被转换为 0000-00-00。请注意，这仍然允许你存储一个无效的日期例如2002-04-31。它允许一个 WEB 应用程序不进行进一步的检查而存储一个表单中的数据。为了确保一个日期值的有效性，在你的应用程序里执行有效性检查。
• 以两位数字指定年份是存在二义性的，因为世纪是未知的。MySQL 以下面的规则解释一个 2 位年份值：
  • 00-69 范围的年份值被转换为 2000-2069。
  • 70-99 范围的年份值被转换为 1970-1999。

6.2.2.3 TIME 类型

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

TIME 值可以多种格式指定：

• 一个 ''''D HH:MM:SS.fraction'''' 格式的字符串。(注意，MySQL 仍然不能为时间列存储毫秒“fraction”)下面所示的任一种“宽松”的语法均可以被使用：HH:MM:SS.fraction、HH:MM:SS、HH:MM、D HH:MM:SS、D HH:MM、D HH 或 SS。这里的 D 是一个在 0-33 之间的日期。
• 一个无定界符的 ''''HHMMSS'''' 格式的字符串，只要字符串看起来像是一个时间。例如：''''101112'''' 可被理解为 ''''10:11:12''''，但是 ''''109712'''' 是不合法的(它有一个无意义的分钟部分)，当被插入时会转换为 ''''00:00:00''''。
• 一个 HHMMSS 格式的数字，只要数字看起来像一个时间。例如，101112 可被理解为 ''''10:11:12''''。下面的任一格式均可被正常理解：SS、MMSS、HHMMSS、HHMMSS.fraction。注意，MySQL 仍不能保存 毫秒(fraction)部分。
• 在一个 TIME 语境中，函数(例如 CURRENT_TIME)的返回值将会返一个合理的格式。

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

将“短”的 TIME 值赋给另一个 TIME 列时要格外小心。如果没有冒号，MySQL 使用最右位代表秒的假设来解释值。(MySQL 将 TIME 值解释为经过的时间，而不是时刻)。例如，你可能会认为 ''''1112'''' and 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'''' 或是一个不合法的值。

6.2.2.4 YEAR 类型

YEAR 类型是一个以 1 个字节描述年份的类型。

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

可以以多个格式指定 YEAR 值：

• 一个在 ''''1901'''' 到 ''''2155'''' 范围之内的 4 位字符串。
• 一个在 1901 到 2155 范围之内的 4 位数字。
• 一个在 ''''00'''' 到 ''''99'''' 范围之内的 2 位字符串。''''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。

6.2.3 字符串类型

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

6.2.3.1 CHAR 和 VARCHAR 类型

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

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

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

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

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

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

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

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

在表创建时，MySQL 可能会隐式地改变一个 CHAR 或 VARCHAR 列的类型。查看章节 6.5.3.1 隐式的列定义变化。

6.2.3.2 BLOB 和 TEXT 类型

一个 BLOB 是一个可以保存一可变数量的数据的二进制大对象。四个 BLOB 类型(TINYBLOB、BLOB、MEDIUMBLOB 和 LONGBLOB)之间的不同仅仅在于他们能保存值的最大长度不一致。查看章节 6.2.6 列类型存储需求。

四个 TEXT 类型(TINYTEXT、TEXT、MEDIUMTEXT 和 LONGTEXT)对应与四个 BLOB 类型，并且有相同的最大长度和存储需求。在 BLOB 和 TEXT 类型之间的唯一差别就是，对 BLOB 值是以字母大小写敏感的方式进行排序和比较的，而对 TEXT 值以忽略字母大小写方式进行排序和比较。换句话说，TEXT 是一个忽略字母大小写的 BLOB。

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

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

• 在 MySQL 3.23.2 和更新的版本中，可以在 BLOB 和 TEXT 列上建立索引。而较老版本的 MySQL 是不支持的。
• 当 BLOB and TEXT 列值被存储时，尾部的空格不会被剪切，这与 VARCHAR 列是不一样的。
• BLOB 和 TEXT 列不可以有 DEFAULT 值。

MyODBC 以 LONGVARBINARY 定义 BLOB 值，以 LONGVARCHAR 定义 TEXT 值。

因为 BLOB

上一页  [1] [2] [3] [4] [5]  下一页