1、字段类型
在设计表时，我们在选择字段类型时，可发挥空间很大。
1、时间格式的数据有：date、datetime和timestamp等等可以选择。
2、字符类型的数据有：varchar、char、text等可以选择。
3、数字类型的数据有：int、bigint、smallint、tinyint等可以选择。
说实话，选择很多，有时候是一件好事，也可能是一件坏事。如何选择一个合适的字段类型，变成了我们不得不面对的问题。
如果字段类型选大了，比如：原本只有1-10之间的10个数字，结果选了bigint，它占8个字节。其实，1-10之间的10个数字，每个数字1个字节就能保存，选择tinyint更为合适。这样会白白浪费7个字节的空间。如果字段类型择小了，比如：一个18位的id字段，选择了int类型，最终数据会保存失败。
所以选择一个合适的字段类型，还是非常重要的一件事情。
以下原则可以参考一下：
尽可能选择占用存储空间小的字段类型，在满足正常业务需求的情况下，从小到大，往上选。
- 如果字符串长度固定，或者差别不大，可以选择char类型。如果字符串长度差别较大，可以选择varchar类型。
- 是否字段，可以选择bit类型。
- 枚举字段，可以选择tinyint类型。
- 主键字段，可以选择bigint类型。
- 金额字段，可以选择decimal类型。
- 时间字段，可以选择timestamp或datetime类型。
2、字段长度
varchar(20) 和 biginit(20)
2.1、那么问题来了，varchar代表的是字节长度，还是字符长度呢？
答：字节长度
varchar (2000) 长度是字节 2000字节，放英文的话，2000个， 中文的话， 1000个中文，utf-8编码，3000字节。
2.2、biginit(n) 这个n表示什么意思呢？
假如我们定义的字段类型和长度是：bigint(4)，bigint实际长度是8个字节。
现在有个数据a=1，a显示4个字节，所以在不满4个字节时前面填充0（前提是该字段设置了zerofill属性），比如：0001。
当满了4个字节时，比如现在数据是a=123456，它会按照实际的长度显示，比如：123456。
但需要注意的是，有些mysql客户端即使满了4个字节，也可能只显示4个字节的内容，比如会显示成：1234。
所以bigint(4)，这里的4表示显示的长度为4个字节，实际长度还是占8个字节。
一般情况下 bigint/int 指定没有意义，会自动填充0
3、字段个数
建议每表的字段个数，不要超过20个。
4、主键
在创建表时，一定要创建主键，如果不创建主键也会有默认主键，只不过占用的是全局主键
主键自带了主键索引，相比于其他索引，主键索引的查询效率最高，因为它不需要回表。
主键还是天然的唯一索引，可以根据它来判重。
在单个数据库中，主键可以通过AUTO_INCREMENT，设置成自动增长的，效率较高。
但在分布式数据库中，特别是做了分库分表的业务库中，主键最好由外部算法(比如：雪花算法）生成，它能够保证生成的id是全局唯一的。
5、字段类型 NOT NULL
在创建字段时，需要选择该字段是否允许为NULL。
我们在定义字段时，应该尽可能明确该字段NOT NULL。
为什么呢？主要有以下原因：
1、在innodb中，需要额外的空间存储null值，需要占用更多的空间。
2、null值可能会导致索引失效。
3、null值只能用is null或者is not null判断，用=号判断永远返回false。
因此，建议我们在定义字段时，能定义成NOT NULL，就定义成NOT NULL。
但如果某个字段直接定义成NOT NULL，万一有些地方忘了给该字段写值，就会insert不了数据。
但有一种情况是，系统有新功能上线，新增了字段。上线时一般会先执行sql脚本，再部署代码。
由于老代码中，不会给新字段赋值，则insert数据时，也会报错。
由此，非常有必要给NOT NULL的字段设置默认值，特别是后面新增的字段。
例如：
alter table product_sku add column brand_id int(10) not null default 0;
6、字符集
mysql中支持的字符集有很多，常用的有：latin1、utf-8、utf8mb4、GBK等。
这4种字符集情况如下：
mysql的字符集使用最多的还是：utf-8和utf8mb4。
其中utf-8占用3个字节，比utf8mb4的4个字节，占用更小的存储空间。
但utf-8有个问题：即无法存储emoji表情，因为emoji表情一般需要4个字节。
由此，使用utf-8字符集，保存emoji表情时，数据库会直接报错。
所以，建议在建表时字符集设置成：utf8mb4，会省去很多不必要的麻烦。
7、排序
utf8mb4_general_ci排序规则，对字母的大小写不敏感。说得更直白一点，就是不区分大小写
而utf8mb4_bin排序规则，对字符大小写敏感，也就是区分大小写。
8、大字段
比如：用户的评论，这就属于一个大字段，但这个字段可长可短。
但一般会对评论的总长度做限制，比如：最多允许输入500个字符。
如果直接定义成text类型，可能会浪费存储空间，所以建议将这类字段定义成varchar类型的存储效率更高。
当然，我还见过更大的字段，即该字段直接保存合同数据。
一个合同可能会占几Mb。
在mysql中保存这种数据，从系统设计的角度来说，本身就不太合理。
像合同这种非常大的数据，可以保存到mongodb中，然后在mysql的业务表中，保存mongodb表的id。
当然，可以对大字段类型数据单独查询
