mysql进阶--数据类型使用上的建议
1 使用 NOT NULL，且带有 COMMENT
这个建议适用于所有的数据类型，MySQL 在索引值为 NULL 的列时，需要额外的存储空间，另外，在进行比较和计算时，MySQL 要对 NULL 值做特别的处理，使用效率较低。
COMMENT 用于定义列的注释信息，加上一些注释，方便以后查阅。
2 使用存储需要的最小数据类型
这里所说的最小数据类型并不是直接选择最小的，而是在满足需求的同时选择最小的。例如，要存储事件状态，可以选择 tinyint；要存储班级人数，可以选择 smallint 等等。关于最小数据类型，它有两大优势：
- 越小的数据类型占用的磁盘、内存、CPU 缓存都会更小，存取速度也会更快
- 小的数据类型建立索引时所需要的空间也相对较小，这样一页中所能存储的索引节点数量也就越多，遍历时 IO 次数就会越少，索引的性能也就越好
3 选择简单的数据类型
这里的 “简单” 二字听上去会比较奇怪，我以一个例子去说明。假如说我想在一列中存储 10、100、201 这样的数据，我们可以选择使用 int 或 varchar 来存储。但是整型要比字符型的操作复杂度小太多，那么，选择整型（例如 int）就是最简单的数据类型。
4 存储小数直接选择 decimal
虽然我并不建议在数据库中存储小数，但是，在一些场景中小数不可避免，最常见的例子就是订单的金额。由于小数本身在计算时就很复杂，而且很多时候你需要去考虑精度问题。所以，最直接的方式就是把这种管理交给数据库。
扩展建议，把数据值 * 100 再去存储。之后，在代码中处理分的逻辑
5 尽量避免使用 text 和 blob
MySQL 内存临时表并不支持 text、blob 这样的大数据类型，如果查询时包含有这样的数据，则排序操作必须使用磁盘临时表，性能会下降很多。而且对于这种数据，MySQL 还要做二次查询（因为 MySQL 实际保存的是指针，而不是真实数据），会使 SQL 性能变得很差。
但是，如果确实有需求需要使用这样的数据类型，那么在查询时一定不要直接 SELECT *，而是取出需要的列
最后，因为 MySQL 对索引长度的限制，text 类型只能用到前缀索引，并且由于存储的是指针，text 列上不能有默认值。
问题:
- 将时间转换为时间戳，并使用 int 或者 bigint 类型去存储，你觉得这样可行吗 ？
完全可以的，时间是整型的话，前端可以方便的进行转换，而且不用考虑精度的问题，且这种转换带来的性能损耗几乎是可以忽略不计的。当然，如果仅仅是 java 系统之间使用的话，使用 datetime 存储是最方便的，序列化和反序列化都只需要一个注解就可以完成
- 大多数时候，我们会选择将主键设置为 bigint 数据类型，你知道这是为什么吗 ？
因为 int 类型的最大表示范围大约是 20 亿，这对于 99% 的项目都基本足够用了。但是，如果考虑到将来业务发展的比较迅速，就需要使用 bigint 了。
