MySQL常用数据类型
1、整型
| MySQL数据类型 | 含义（有符号） |
| tinyint(m) | 1个字节 范围(-128~127) |
| smallint(m) | 2个字节 范围(-32768~32767) |
| mediumint(m) | 3个字节 范围(-8388608~8388607) |
| int(m) | 4个字节 范围(-2147483648~2147483647) |
| bigint(m) | 8个字节 范围(+-9.22*10的18次方) |
取值范围如果加了unsigned，则最大值翻倍，如tinyint unsigned的取值范围为(0~256)。
int(m)里的m是表示SELECT查询结果集中的显示宽度，并不影响实际的取值范围，没有影响到显示的宽度，不知道这个m有什么用。
2、浮点型(float和double)
| MySQL数据类型 | 含义 |
| float(m,d) | 单精度浮点型 8位精度(4字节) m总个数，d小数位，默认是10, 2 |
| double(m,d) | 双精度浮点型 16位精度(8字节) m总个数，d小数位，默认是16, 4 |
设一个字段定义为float(5,3)，如果插入一个数123.45678,实际数据库里存的是123.457，但总个数还以实际为准，即6位。
3、定点数
浮点型在数据库中存放的是近似值，而定点类型在数据库中存放的是精确值。
decimal(m,d) 参数m<65 是总个数，d<30且 d<m 是小数位。
4、字符串(char,varchar,_text)
| MySQL数据类型 | 含义 |
| char(n) | 固定长度，最多255个字符 |
| varchar(n) | 可变长度，最多65535个字符 |
| tinytext | 可变长度，最多255个字符 |
| text | 可变长度，最多65535个字符 |
| mediumtext | 可变长度，最多2的24次方-1个字符 |
| longtext | 可变长度，最多2的32次方-1个字符 |
char和varchar：
1.char(n) 若存入字符数小于n，则以空格补于其后，查询之时再将空格去掉。所以char类型存储的字符串末尾不能有空格，varchar不限于此。
2.char(n) 固定长度，char(4)不管是存入几个字符，都将占用4个字节，varchar是存入的实际字符数+1个字节（n<=255）或2个字节(n>255)，所以varchar(4),存入3个字符将占用4个字节。
3.char类型的字符串检索速度要比varchar类型的快。
varchar和text：
1.varchar可指定n，text不能指定，内部存储varchar是存入的实际字符数+1个字节（n<=255）或2个字节(n>255)，text是实际字符数+2个字节。
2.text类型不能有默认值。
3.varchar可直接创建索引，text创建索引要指定前多少个字符。varchar查询速度快于text,在都创建索引的情况下，text的索引似乎不起作用。
5.二进制数据(_Blob)
1._BLOB和_text存储方式不同，_TEXT以文本方式存储，英文存储区分大小写，而_Blob是以二进制方式存储，不分大小写。
2._BLOB存储的数据只能整体读出。
3._TEXT可以指定字符集，_BLO不用指定字符集。
6.日期时间类型
| MySQL数据类型 | 含义 |
| date | 日期 '2008-12-2' |
| time | 时间 '12:25:36' |
| datetime | 日期时间 '2008-12-2 22:06:44'。原样存入和读出；可表示范围大。 |
| timestamp | 格式与datetime一样。不过创建或修改所在行时会自动修改时间；存入时自动转为UTC（世界标准世界，即零时区）存储，读出时自动转为当前时；可表示范围较小。 |
timestamp特别之处：若定义一个字段为timestamp，则在插入一条数据时该字段值会自动更新为当前时间，且也可以随其他字段的修改而自动更新为当前时间（可以配置），所以这个数据类型的字段可以存放这条记录最后被修改的时间。（参考 https://www.cnblogs.com/ivictor/p/5028368.html）
可以通过 show create table tb_name; 查看包含timestamp类型字段的表的完整建表语句，示例：
| user | CREATE TABLE `user` ( `id` varchar(36) NOT NULL COMMENT '用户id', `username` varchar(45) NOT NULL COMMENT '账号名称', `password` varchar(255) NOT NULL COMMENT '用户密码', `lastlogintime` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最近登录时间', PRIMARY KEY (`id`), UNIQUE KEY `username_UNIQUE` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8
DEFAULT CURRENT_TIMESTAMP指定了创建新行时该字段自动更新为当前时间
ON UPDATE CURRENT_TIMESTAMP指定了更新某行其他字段时该字段自动更新为当前时间
timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAM指定创建和更新其他字段时都自动更新时间值。可以指定只在创建时自动更新 或 只在更新其他字段时自动更新。
datatime与timestamp的区别：
timestamp原样存入和读出；所能存储的时间范围为：'1970-01-01 00:00:01.000000' 到 '2038-01-19 03:14:07.999999'。
datetime转为UTC存入、读出转为所在时区；所能存储的时间范围为：'1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'。
总结：TIMESTAMP和DATETIME除了存储范围和存储方式不一样，没有太大区别。当然，对于跨时区的业务，TIMESTAMP更为合适。
上面说了一堆（网上摘抄的）好像不完全准确。自我总结两者异同：
相同点：
表现格式一致，包含日期、时间；
时间都可以精确到微妙（6位小数）
不同点
存储空间：temestamp 4字节、datetime 8字节
表示的范围：
temestamp：1970-01-01 00:00:01.000000 UTC 到 ``2038-01-09 03:14:07.999999 UTC，注意是1970年第一秒而非0秒，这点踩过坑
datetime：1000-01-01 00:00:00.000000 到 9999-12-31 23:59:59.999999；
7.MySQL5.7开始支持json类型存储
（具体参考MySQL5.7 的 JSON 实现-taobao.org）
如果MySQL不支持JSON，则用户可以借助BLOB实现JSON存储，但存在问题：
- 需要用户保证 JSON 的正确性，如果用户插入的数据并不是一个有效的 JSON 字符串，MySQL 并不会报错；
- 所有对 JSON 的操作，都需要在用户的代码里进行处理，不够友好；
- 即使只是提取 JSON 中某一个字段，也需要读出整个 BLOB，效率不高；
- 无法在 JSON 字段上建索引。
MySQL5.7开始支持JSON类型数据存储，其实现方法也是将JSON类型数据序列化为BLOB类型存储，并加了一些元数据来支持部分JSON字段的查询，而不需要像不支持JSON前那样用户需要取出整个JSON。
首先存放的是 JSON 的元素个数，然后存放的是转换成 BLOB 以后的字节数，接下来存放的是key pointers和value pointers。为了加快查找速度，MySQL 内部会对key进行排序，以便对key进行二分查找，以提高处理速度。
可以看出，对于JSON数据，从用户层面看，采用JSON类型存储比采用BLOB存储会占用更多空间，但对用户使用来说可能会更便利。
数据类型的属性
| MySQL关键字 | 含义 |
| NULL | 数据列可包含NULL值 |
| NOT NULL | 数据列不允许包含NULL值 |
| DEFAULT | 默认值 |
| PRIMARY KEY | 主键 |
| AUTO_INCREMENT | 自动递增，适用于整数类型 |
| UNSIGNED | 无符号 |
| CHARACTER SET name | 指定一个字符集 |
