选自“潇洒哥和黑大帅”公众号，一个程序员和他的爱情故事。
不使用enum
首先说一下优点，可以控制插入字符的选项，规范数据。那说说有哪些缺点，如下：
- 不方便扩展：后期如果增加选项，如果不是插入到最后，那 enum 的索引就会调整
- 保存要注意：如果存储数字字符串时，一定要带引号，如果不带，会视为索引
总结：如果你的内容是固定的，后期不会增加，那可以选择 enum ，例如：男、女。那如果是状态类的，后期会根据业务增加新状态，那就使用 tinyint(1) 。
不使用外键
这是一个把约束最终交给数据库还是程序的问题，我在这说说我的几点看法。
- 性能：没有了外键约束，那自然性能会提高。
- 可读性：有外键约束，增加 ER 图的可读性，方便查看表之间的关系。
- 完整性：有外键约束，可以在数据库层面控制数据的完整性，不会造成一个表有数据，一个表没有。但如果我进行数据的部分保全，那使用外键就是个约束。
说了这几点后， 自然也明白了我不选择使用外键的原因。
不存储NULL值
当保存字符串数据是空的时候，往往有两种选择，空字符串或NULL。那如何选择呢，我这里先给出建议，选择空字符串（默认空字符串），原因如下：
- 空值不占空间，NULL值占空间。当字段不为NULL时，也可以插入空值。
- 当使用 IS NOT NULL 或者 IS NULL 时，只能查出字段中没有不为NULL的或者为 NULL 的，不能查出空值。
- 在进行count()统计某列的记录数的时候，如果采用的NULL值，系统会自动忽略掉，但是空值是会进行统计到其中的。
TIMESTAMP和DATETIME
-
存储方式
对于TIMESTAMP，它把客户端插入的时间从当前时区转化为UTC（世界标准时间）进行存储。查询时，将其又转化为客户端当前时区进行返回。
而对于DATETIME，不做任何改变，基本上是原样输入和输出。
范围
- DATETIME 时间截至到 9999-12-31 23:59:59
- TIMESTAMP 时间截止到 2038-1-19 11:14:07
- 自动填充时间
mysql5.6 之前 TIMESTAMP 支持如下语法，5.6之后 DATETIME 才支持
-- 创建时自动填充当前时间
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
-- 创建和修改时自动填充当前时间
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
- 总结
如果不考虑时间的截至日期，我考虑选择 TIMESTAMP，因为可以兼容不同版本的时间填充和时区控制。
字符集和排序规则
在创建数据库时，需要设定字符集和排序规则。
先说字符集，推荐使用 utf8mb4 ，这个包含目前所有的信息存储，例如：emoji表情、所有语言
-
排序规则
- utf8_general_ci 不区分大小写，这个你在注册用户名和邮箱的时候就要使用。
- utf8_general_cs 区分大小写，如果用户名和邮箱用这个 就会照成不良后果
- utf8_bin:字符串每个字符串用二进制数据编译存储。 区分大小写，而且可以存二进制的内容
注意：一般选择 utf8_general_ci ，它在where 语句进行比对查询时，速度很快。
不使用bit类型
在设计表时，如果出现状态之类的字段。例如：0 代表男，1 代表女。使用 tinyint(1) 代替。原因如下：
-
不能节省空间大小
刚开始我从字面意思理解 bit(1) 只占用了 1 bit（位）（1字节等于8bit），那真实情况是什么，查看官网文档后发现，bit(M) 的存储空间大约是 (M+7)/8 字节，也就是说 bit(1) 存储的大小不是 1位，而是1 字节
-
使用上的不便
mysql中的二进制类型，存储数据时使用 B'1111100' 或 b'1111100' ，读取数据时使用 bin(column_name)。
少用text类型
查询速度: char > varchar > text
- 存储的数据长度固定，选择char类型
- 不固定的话使用varchar，避免使用text，如果varchar长度不够时可以增加长度。在业务方面内容长度最好得到规范和控制。
以上是我在实际开发中所总结的一些经验，如果你还有其它说的，请在评论区补充。
