整数类型
实数类型
字符串类型
日期和韶光类型
设计合理的数据类型
1. 整数类型整数类型有：tinyint、smallint、mediumint、int、bigint，分别利用 8、16、24、32、64 位存储空间。它们可以存储的值范围从 -2 的 (n-1) 次方到 2 的 (n-1) 次方 -1，n 是存储空间的位数。
整数有可选的 unsigned 属性（无符号类型），表示不许可有负值，因此可以使正数上限提高一倍。
有符号和无符号类型利用相同的存储空间，并具有相同的性能，因此可以根据实际情形选择得当的类型。
2. 实数类型实数类型有：FLOAT、DOUBLE ，分别占用 4，8 字节。
如果插入值的精度（即：数字总位数）高于实际定义的精度，系统会自动进行四舍五入处理，使值的精度达到哀求。
个中 DECIMAL 也可以用来指定精度，并且它比 FLOAT 和 DOUBLE 更适宜做精确打算。在本文就不做详细先容了，如果有人想理解的话可以给我留言，我下次再写。
3. 字符串类型字符串类型有：
VARCHARCHARBLOBTEXT由于 BLOB 和 TEXT 不常用且由于篇幅问题，就不展开描述了。本文紧张对 VARCHAR 和 CHAR 进行先容，它们的差异如下表：
比拟内容VARCHARCHAR是否固定长度否是存储上限字节65535255保存或检索值时，是否删除字符串末端空格否是超过设置的范围后，字符串是否会被截断否是
除了以上不同之外，VARCHAR 还须要额外利用 1 个或 2 个字节来记录字符串长度。如果列的最大长度小于或即是 255 字节，则利用 1 个字节，否则利用 2 个字节。
由于 VARCHAR 是变长的，以是在 update 时，可能使行变得比原来更长，这就导致须要进行额外的事情。如果一个行占用的空间增加，并且在页内没有更多空间可以存储，在这种情形下，不同存储引擎的处理办法不一样的。例如：MyISAM 会将行拆分为不同的片段存储，InnoDB 则须要分裂页来使行可以放进页内。
在选择利用场景上，重点要捉住 VARCHAR 是变长，CHAR 是定长的特点。
比如在这些情形更适宜利用 VARCHAR：
字符串的最大长度比均匀长度大很多；字段更新次数少（以是碎片不是问题）；利用了像 UTF-8 这样繁芜的字符集，每个字符都利用不同的字节数进行存储。而在这些情形则更适宜利用 CHAR：
存储很短的字符串（而 VARCHAR 还要多一个字节来记录长度，本来打算节约存储的现在反而得不偿失落）定长的字符串（如 MD5、uuid）；须要频繁修正的字段。由于 VARCHAR 每次存储都要有额外的打算，得到长度等事情；这里抛出一个小问题：利用 VARCHAR(5) 和 VARCHAR(200) 来存储 ‘hello’ 的空间开销是一样的。那么利用更短的列有什么好处呢？（思考几秒钟？）
答案：节约内存，由于更长的列会花费更多的内存。MySQL 常日会分配固定大小的内存块来保存内部值。尤其是利用内存临时表进行排序或操作时会特殊糟糕。在利用磁盘临时进行排序时也同样糟糕。
以是最好的策略是只分配真正须要的空间。
4. 日期和韶光类型下面表格是 TIMESTAMP 和 DATETIME 的一些比拟：
比拟内容TIMESTAMPDATETIME占用字节48韶光范围1970-01-01 08:00:01 ～ 2038-01-19 11:14:071000-01-01 00:00:00 ~ 9999-12-31 23:59:59存储的数据是否随时区变革是否
如果在插入数据时，没有指定第一个 TIMESTAMP 列的值，MySQL 则将这个列设置为当前韶光，同时 TIMESTAMP 比 DATETIME 的空间效率更高。
末了，网上有很多谈论，韶光到底要利用 INT、TIMESTAMP、DATETIME 哪种类型更适宜。我认为这没有一个固定答案，得当的就好……。
5. 设计合理的数据类型供应给大家 3 点设计原则：
更小的常日更好大略就好只管即便避免 NULL下面对其详细解释一下：
一样平常情形下，该当选择可以精确存储数据的最小数据类型，由于它们占用更少的磁盘、内存和 CPU 缓存，并且处理时须要的 CPU 周期也更少。大略数据类型的操作须要更少的 CPU 周期。例如，整型比字符操作代价更低，由于字符集和校正规则（排序规则）使字符比较比整型比较更繁芜。常日情形下，最好指定列为 NOT NULL，除非真的须要存储 NULL 值。由于可为 NULL 的列会使索引、索引统计和值比较都更繁芜。可为 NULL 的列会利用更多的存储空间，在 MySQL 里也须要分外处理。当可为 NULL 的列被索引时，每个索引须要一个额外的字节，在 MyISAM 里乃至还可能导致固定大小的索引变成可变大小的索引。常日把可为 NULL 的列改为 NOT NULL 带来的性能比较小，以是在优化时没有必要先在现有表里修正这种情形。参考：
《高性能 MySQL》
