MySQL零散笔记-- 数据类型

今天准备进行毕设的数据库设计，所以google了一下MySQL的数据库设计原则，主要是数据类型和表设计，为了怕自己忘记整理出来。

Reference 文章：MySQL 字段类型 作者：simaopig

类型	描述
INT	一种数值类型，值的范围如下 带符号的-2147483648~2147483647 不带符号的0~4294967295 最多十位，所以存手机号是不行的
DECIMAL	一种数值类型，支持浮点数或者小数
DOUBLE	一种数值类型，支持双精度浮点数
DATE	YYYYMMDD格式的日期字段
TIME	HH:MM:SS格式的时间字段
DATETIME	YYMMDD HH:MM:SS格式的日期/时间类型.注意“年月日”与“时分秒”之间的空格
YEAR	以YYYY或YY格式，范围在1901~2155之间指定的年字段 别问我2155年后咋办，我估计我活不到那年
TIMESTAMP	以YYYYMMDDHHMMSS格式的时间戳
CHAR	最大长度为255个字符且有固定长度的字符串类型
VARCHAR	最大长度为255个字符但是变长的字符串类型
TEXT	最大长度为65535个字符的字符串的类型
BLOB	可变数据的二进制类型
ENUM	可以从定义数值的列表上接受值的数据类型
SET	可以从定义数值的集合上接受0个或者多个值的数据类型

 

一些例子代码：

CREATE TABLE data (id TINYINT );

INSERT INTO data VALUES (123456789);

SELECT id FROM data;

因为TINYINT的存储范围是（-128，127），所以查询结果为127。

CREATE TABLE data (speed FLOAT(3,1));

INSERT INTO data VALUES(123.765);

SELECT speed FROM data

其查询结果为123.8这就是四舍五入的结果

默认情况下,MySQL是大小写不敏感的，例如：

CREATE TABLE data (name CHAR(5));

INSERT INTO data VALUES ('HUGO');

SELECT * FROM data WHERE name = 'hugo'

hugo会被搜出来。

BINARY关键字，它告诉MySQL， 之后的字符串应该以二进制方式被处理。这时，当在字符串上执行比较运算符时，MySQL将牢牢记住字符串的大小写。CHAR和VARCHAR都适用此修饰符。

ALTER TABLE data CHANGE CHAR（5） BINARY;

SELECT * FROM data WHERE name = 'hugo'

这样就好啦！就找不到hugo了

“CHAR类型和VACHAR之间的差别在于MySQL处理这个指示器（长度指示器）的方式不同：CHAR把这个大小视为值的准确大小（用空格填补比较短的值，所以达到了这个大小），而VARCHAR类型把它视为最大值并且只使用了在存储字符串实际上需要的字节数（增加一个额外的字节记录长度）”

“TEXT和BLOB类型在分类和比较的方式上不同，BLOB类型区分大小写，TEXT类型不区分大小写。MySQL手册用“TEXT类型是不区分大小写的BLOB类型”最准确地说明了这一点。”

CREATE TABLE data (birthday DATE);

INSERT INTO data VALUES ('2009-04-07'),(20090407);

SELECT birthday FROM data;

结果都是”2009-04-07″， MySQL默认使用'-'分隔日期,用':'分隔时间

DROP TABLE data;

CREATE TABLE data (showtime TIME);

INSERT INTO data VALUES('12:30:56'),('12:30'),(123056);

SELECT showtime FROM data;

查询结果为“12:30:56″,”12:30:00″,”12:30:56″.

MySQL还对日期的年份中的两个数字的值，或是语句为YEAR类型的输入字段中的两个数字输入执行这种类型的最大限度的通译。因为所有的YEAR类型的值必须用4个数字来存储，所有MySQL试图根据值的数字范围把两个数字的年份值转换为4个数字的值：把在00~69范围内的值转换到2000~2069范围内，而把70~99范围内的值转换到1970~1979之内。

问题：

数据类型如何设计？用户ID使用数值型还是字符型为好？

一些搜来的建议：

ID类型的文本字段，比如客户 ID或定单号等等都应该设置得比一般想象更大，因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说，假设你的客户ID为 10位数长。那你应该把数据库表字段的长度设为12或者 13个字符长。这算浪费空间吗？是有一点，但也没你想象的那么多：一个字段加长 3个字符在有1百万条记录，再加上一点索引的情况下才不过让整个数据库多占据3MB的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。