正文
唯一索引，可以加 ux_ 前缀，比如：ux_product_code。
2.字段类型
在设计表时，我们在选择字段类型时，可发挥空间很大。
时间格式的数据有：date、datetime 和 timestamp 等等可以选择。
字符类型的数据有：varchar、char、text 等可以选择。
数字类型的数据有：int、bigint、smallint、tinyint 等可以选择。
说实话，选择很多，有时候是一件好事，也可能是一件坏事。
如何选择一个合适的字段类型，变成了我们不得不面对的问题。
如果字段类型选大了，比如：原本只有 1-10 之间的 10 个数字，结果选了 bigint，它占 8 个字节。
其实，1-10 之间的 10 个数字，每个数字1个字节就能保存，选择 tinyint 更为合适。
如果字段类型择小了，比如：一个 18 位的 id 字段，选择了 int 类型，最终数据会保存失败。
所以选择一个合适的字段类型，还是非常重要的一件事情。
以下原则可以参考一下：
-
尽可能选择占用存储空间小的字段类型，在满足正常业务需求的情况下，从小到大，往上选。
-
如果字符串长度固定，或者差别不大，可以选择char类型。如果字符串长度差别较大，可以选择 varchar 类型。
-
-
-
-
-
时间字段，可以选择 timestamp 或 datetime 类型。
3.字段长度
前面我们已经定义好了字段名称，选择了合适的字段类型，接下来，需要重点关注的是字段长度了。
比如：varchar(20)，biginit(20) 等。
那么问题来了，varchar 代表的是字节长度，还是字符长度呢？
答：在
M
ySQL
中除了 varchar 和 char 是代表字符长度之外，其余的类型都是代表字节长度。
biginit(n) 这个 n 表示什么意思呢？
假如我们定义的字段类型和长度是：bigint(4)，bigint 实际长度是 8 个字节。
现在有个数据 a=1，a 显示 4 个字节，所以在不满 4 个字节时前面填充 0（前提是该字段设置了 zerofill 属性），比如：0001。
当满了 4 个字节时，比如现在数据是 a=123456，它会按照实际的长度显示，比如：123456。
但需要注意的是，有些
M
ySQL
客户端即使满了 4 个字节，也可能只显示 4 个字节的内容，比如会显示成：1234。
所以 bigint(4)，这里的4表示显示的长度为 4 个字节，实际长度还是占 8 个字节。
4.字段个数
我之前见过有人创建的表，有几十个，甚至上百个字段，表中保存的数据非常大，查询效率很低。
如果真有这种情况，可以将一张大表拆成多张小表，这几张表的主键相同。
5. 主键
因为主键自带了主键索引，相比于其他索引，主键索引的查询效率最高，因为它不需要回表。
在单个数据库中，主键可以通过 AUTO_INCREMENT，设置成自动增长的。
但在分布式数据库中，特别是做了分库分表的业务库中，主键最好由外部算法(比如：雪花算法）生成，它能够保证生成的id是全局唯一的。
除此之外，主键建议保存跟业务无关的值，减少业务耦合性，方便今后的扩展。
不过我也见过，有些一对一的表关系，比如：用户表和用户扩展表，在保存数据时是一对一的关系。
这样，用户扩展表的主键，可以直接保存用户表的主键。
6.存储引擎
在
M
ySQL
8 以前的版本，默认的存储引擎是 myisam，而
M
ySQL
8 以后的版本，默认的存储引擎变成了 innodb。
之前我们还在创建表时，还一直纠结要选哪种存储引擎？
myisam 的索引和数据分开存储，而有利于查询，但它不支持事务和外键等功能。
而 innodb 虽说查询性能，稍微弱一点，但它支持事务和外键等，功能更强大一些。
以前的建议是：读多写少的表，用 myisam 存储引擎。而写多读多的表，用 innodb。
但虽说
M
ySQL
对 innodb 存储引擎性能的不断优化，现在 myisam 和 innodb 查询性能相差已经越来越小。
所以，建议我们在使用
M
ySQL
8 以后的版本时，直接使用默认的 innodb 存储引擎即可，无需额外修改存储引擎。
7. NOT NULL
在创建字段时，需要选择该字段是否允许为 NULL。
