Mysql支持的类型大概可分为数字、日期、字符串 下面分别介绍：
| ——- | ——- | ———– | ——– |
| TINYINT | 1字节 | (-128，127) | 特小整数 |
| SMAILINT | 2字节 | (-215,215-1) | 小整数 |
| MEDIUMINT| 3字节 | (-223,223-1) | 中等整数 |
| INT | 4字节 | (-231,231-1) | 整数 |
| BIGINT | 8字节 | (-263,263-1) | 大整数 |
| FLOAT | 4字节 | (-2128,2128) | 单精度浮点|
| DOUBLE | 8字节 |(-21024,21024)| 双精度浮点|
| DECIMAL | 不确定 | 不确定 | 精确计算 |
REAL是DOUBLE的同义词，NUMERIC是DECIMAL的同义词。 FLOAT和DOUBLE的范围我写的不是特别精确，因为这实际上依赖于Mysql运行的平台是如何实现的。不过它们都拥有一个靠近自然数0的最小值，不能平滑地过渡到无穷小 另外，这里列出的都是有符号类型的范围。无符号类型的话，就是在前面加上UNSIGNED关键字，范围都会变成正数。 如何记忆范围里的数字呢？其实不用死记硬背，只需要记得前面占用几个字节即可，1个字节等于8bit，因此就是2的8次方。有符号数的范围由于一个bit用来记录正负，因此只能取到负的2的7次方到2的7次方-1。
除此之外，还有BINARY、VARBINARY、ENUM、SET四种类型 CHAR和VARCHAR: - VARCHAR是变长的，即数据多长，就占用多长的存储空间，比较省空间 - VARCHAR需要额外的1个字节来存储字符串长度，如果字符串长度大于255，则需要2个额外的字节 - VARCHAR不太适合更新频繁的场景，因为当长度改变后，行的长度就改变了，存储引擎需要做额外的工作，影响性能，产生碎片。 - Mysql5.0或更高版本，会在存储和检索时保留VARCHAR的空格，CHAR末尾的空格会被自动去除 - CHAR适合频繁更新，字符串长度不怎么变的场景，比如存放MD5 - InnoDB这个存储引擎会把过长的VARCHAR转成TEXT - 虽然VARCHAR是变长的，但是建表的时候，还是要分配真实需要的空间，不要取得过大，因为这会导致Mysql在使用内存临时表排序或者操作时消耗更多的内存
BINARY和VARBINARY: - 和CHAR、VARCHAR是类似的，不同的是，存储的是二进制字符串，这样存储的是字节码而不是字符，就与字符集无关了 - 由于存储的是字节码，因此比较起来比字符简单，故查询的性能应该好一些 - 填充采用的是\0而不是空格(由于我看的书是中文翻译，所以这里我没看懂什么意思……哎，还是原生好啊)
BLOB和TEXT: - 它们都是为了存储很大的数据设计的字符串数据类型(这里我就要吐槽一下既然如此为什么还有TINYBLOB这种东西……) - SMALLBLOB=BLOB,SMALLTEXT=TEXT，即它们是同义词 - 这两种类型当值太大时，Mysql会在行内存储它们的指针，实际内容放在外部单独的区域存储。 - BLOB和TEXT的区别就是BLOB存储的是二进制的数据，没有字符集也没有排序规则而TEXT有。 - BLOB和TEXT列进行排序和其他的不同，只会对最前面max_sort_length个字节做排序，用户可以手动设置这个值也可以使用 ORDER BY SUSTRING(column,length) 来指定取前多少个字符排序。 - Mysql没法对BLOB、TEXT列全部长度的字符串进行索引
ENUM: - 枚举类型是特殊的字符串类型，定义枚举列后，真正存在表中的是整数，表的.frm文件则保存整数和枚举字符串的映射关系 - 如：CREATE TABLE enum_test(e ENUM('fish','apple','dog') NOT NULL);在表中，真正存储的是，1、2、3这样的数字 - 不要使用数字作为枚举字符串常量，如ENUM(‘1’,‘2’,‘3’)。这样会导致混乱 - 枚举的顺序是按照背地里的数字来排序的，因此，你的Order by语句可能得不到按字符串排序的结果。解决方案就是声明的时候就把字符串排好序，枚举常量对应的数字是和声明时的顺序有关的。还有一种方案是使用如下FIELD语句：
SELECT e FROM enum_test ORDER BY FIELD(e,'apple','dog','fish');