MYSQL教程之MySQL字段范例申明

MySQL的低成本来自于其简单性吗?它的普及性是由于其低成本吗?其实，在MySQL的最“好”与最“不好”的功能之间没有明显的分界线，但它们组合在一起就形成了一副让我们欣赏的作品。MySQL撑持大批的列范例，它能够被分为3类：数字范例、日期和工夫范例和字符串(字符)范例。本节起首给出可用范例的一个概述，而且总结每一个列范例的存储需求，然后供应每一个类中的范例性子的更具体的形貌。概述成心简化，更具体的申明应当思索到有关特定列范例的附加信息，比方你能为其指定值的同意格局。
由MySQL撑持的列范例列鄙人面。以下代码字母用于形貌中：
M
指出最年夜的显现尺寸。最年夜的正当的显现尺寸是255。
D
合用于浮点范例而且指出跟从在十进制小数点后的数码的数目。最年夜大概的值是30，可是应当不年夜于M-2。
方括号(“[”和“]”)指出可选的范例润色符的部分。
注重，假如你指定一个了为ZEROFILL，MySQL将为该列主动地增添UNSIGNED属性。
TINYINT[(M)][UNSIGNED][ZEROFILL]
一个很小的整数。有标记的局限是-128到127，无标记的局限是0到255。

SMALLINT[(M)][UNSIGNED][ZEROFILL]
一个小整数。有标记的局限是-32768到32767，无标记的局限是0到65535。
MEDIUMINT[(M)][UNSIGNED][ZEROFILL]
一其中等巨细整数。有标记的局限是-8388608到8388607，无标记的局限是0到16777215。
INT[(M)][UNSIGNED][ZEROFILL]
一个一般巨细整数。有标记的局限是-2147483648到2147483647，无标记的局限是0到4294967295。
INTEGER[(M)][UNSIGNED][ZEROFILL]
这是INT的一个同义词。
BIGINT[(M)][UNSIGNED][ZEROFILL]
一个年夜整数。有标记的局限是-9223372036854775808到9223372036854775807，无标记的局限是0到
18446744073709551615。注重，一切算术运算用有标记的BIGINT或DOUBLE值完成，因而你不该该利用年夜于9223372036854775807（63位)的有标记年夜整数，除位函数！注重，当两个参数是INTEGER值时，-、+和*将利用BIGINT运算！这意味着假如你乘2个年夜整数(或来自于前往整数的函数)，假如了局年夜于9223372036854775807，你能够失掉不测的了局。一个浮点数字，不克不及是无标记的，对一个单精度浮点数，其精度能够是<=24，对一个双精度浮点数，是在25和53之间，这些范例如FLOAT和DOUBLE范例即刻鄙人面形貌。FLOAT(X)有对应的FLOAT和DOUBLE不异的局限，可是显现尺寸和小数位数是不决义的。在MySQL3.23中，这是一个真实的浮点值。在更早的MySQL版本中，FLOAT(PRecision)老是有2位小数。该句法为了ODBC兼容性而供应。
FLOAT[(M,D)][ZEROFILL]
一个小(单严密)浮点数字。不克不及无标记。同意的值是-3.402823466E+38到-1.175494351E-38，0和1.175494351E-38到3.402823466E+38。M是显现宽度而D是小数的位数。没有参数的FLOAT或有<24的一个参数暗示一个单严密浮点数字。
DOUBLE[(M,D)][ZEROFILL]
一个一般巨细(双严密)浮点数字。不克不及无标记。同意的值是-1.7976931348623157E+308到-2.2250738585072014E-308、0和2.2250738585072014E-308到1.7976931348623157E+308。M是显现宽度而D是小数位数。没有一个参数的DOUBLE或FLOAT(X)（25<=X<=53）代表一个双严密浮点数字。
DOUBLEPRECISION[(M,D)][ZEROFILL]
　
REAL[(M,D)][ZEROFILL]
这些是DOUBLE同义词。
DECIMAL[(M[,D])][ZEROFILL]
一个未紧缩(unpack)的浮点数字。不克不及无标记。举动好像一个CHAR列：“未紧缩”意味着数字作为一个字符串被存储，值的每位利用一个字符。小数点，而且关于正数，“-”标记不在M上钩算。假如D是0，值将没有小数点或小数部分。DECIMAL值的最年夜局限与DOUBLE不异，可是对一个给定的DECIMAL列，实践的局限能够经由过程M和D的选择被限定。假如D被省略，它被设置为0。假如M被免却，它被设置为10。注重，在MySQL3.22里，M参数包含标记和小数点。
NUMERIC(M,D)[ZEROFILL]
这是DECIMAL的一个同义词。
DATE
一个日期。撑持的局限是1000-01-01到9999-12-31。MySQL以YYYY-MM-DD格局来显现DATE值，可是同意你利用字符串或数字把值赋给DATE列。
DATETIME
一个日期和工夫组合。撑持的局限是1000-01-0100:00:00到9999-12-3123:59:59。MySQL以YYYY-MM-DDHH:MM:SS格局来显现DATETIME值，可是同意你利用字符串或数字把值赋给DATETIME的列。
TIMESTAMP[(M)]
一个工夫戳记。局限是1970-01-0100:00:00到2037年的某时。MySQL以YYYYMMDDHHMMSS、YYMMDDHHMMSS、YYYYMMDD或YYMMDD格局来显现TIMESTAMP值，取决因而否M是14（或省略)、12、8或6，可是同意你利用字符串或数字把值赋给TIMESTAMP列。一个TIMESTAMP列关于纪录一个INSERT或UPDATE操纵的日期和工夫是有效的，由于假如你不本人给它赋值，它主动地被设置为比来操纵的日期和工夫。你以能够经由过程赋给它一个NULL值设置它为以后的日期和工夫。
TIME
一个工夫。局限是-838:59:59到838:59:59。MySQL以HH:MM:SS格局来显现TIME值，可是同意你利用字符串或数字把值赋给TIME列。
YEAR[(2|4)]
一个2或4位数字格局的年(缺省是4位)。同意的值是1901到2155，和0000（4位年格局），假如你利用2位，1970-2069(70-69)。MySQL以YYYY格局来显现YEAR值，可是同意你把利用字符串或数字值赋给YEAR列。（YEAR范例在MySQL3.22中是新范例。）
CHAR(M)[BINARY]
一个定长字符串，当存储时，老是是用空格填满右侧到指定的长度。M的局限是1～255个字符。当值被检索时，空格尾部被删除。CHAR值依据缺省字符集以巨细写不辨别的体例排序和对照，除非给出BINARY关头词。NATIONALCHAR（短情势NCHAR)是ANSISQL的体例来界说CHAR列应当利用缺省字符集。这是MySQL的缺省。CHAR是CHARACTER的一个缩写。
[NATIONAL]VARCHAR(M)[BINARY]
一个变长字符串。注重：当值被存储时，尾部的空格被删除(这分歧于ANSISQL标准)。M的局限是1～255个字符。VARCHAR值依据缺省字符集以巨细写不辨别的体例排序和对照，除非给出BINARY关头词值。VARCHAR是CHARACTERVARYING一个缩写。
TINYBLOB
　
TINYTEXT
一个BLOB或TEXT列，最年夜长度为255(2^8-1)个字符。
BLOB
　
TEXT
一个BLOB或TEXT列，最年夜长度为65535(2^16-1)个字符。
MEDIUMBLOB
　
MEDIUMTEXT
一个BLOB或TEXT列，最年夜长度为16777215(2^24-1)个字符。
LONGBLOB
　
LONGTEXT
一个BLOB或TEXT列，最年夜长度为4294967295(2^32-1)个字符。
ENUM(value1,value2,...)
列举。一个唯一一个值的字符串工具，这个值式选自与值列表value1、value2,...,或NULL。一个ENUM最多能有65535分歧的值。
SET(value1,value2,...)
一个汇合。能有零个或多个值的一个字符串工具，个中每个必需从值列表value1,value2,...选出。一个SET最多能有64个成员。
出处：记事阁
在我们工作的过程中，经常能听到很多不使用MySQL的理由，虽然其中有一些是对MySQL的误解，不过同样也有一些是合情合理的。

你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。

分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。

我个人认为就是孜孜不懈的学习

SQLServer的异构移植功能个人感觉最好了。（如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）

你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。

至于淘汰的问题，只能说在你的项目周期之内，微软应该都不会倒闭。

XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）