数据库表设计规范
1.1、主键：
- 表必须有主键；
- 不使用更新频繁的列做主键；
- 尽量不选择字符串列做主键；
- 不使用 UUID MD5 HASH 做主键；
- 默认使用非空的唯一键。
1.2、如无特殊要求，建议都使用 InnoDB 引擎；
1.3、默认使用 utf8mb4 字符集，数据排序规则使用 utf8mb4_general_ci；
原因：utf8mb4 为万国码，无乱码风险；与 utf8 编码相比，utf8mb4 能支持 Emoji 表情。
1.4、所有表、字段都需要增加 comment 来描述此表、字段所表示的含义；
比如：data_status TINYINT NOT NULL DEFAULT ‘1’ COMMENT ‘1代表记录有效，0代表记录无效’。
1.5、如无说明，表必须包含 create_time 和 update_time 字段，即表必须包含记录创建时间和修改时间的字段；
1.6、用尽量少的存储空间来存数一个字段的数据：
- 能用 int 的就不用 char 或者 varchar；
- 能用 tinyint 的就不用 int；
- 使用 UNSIGNED 存储非负数值；
- 只存储年使用 YEAR 类型；
- 只存储日期使用 DATE 类型。
1.7、存储精确浮点数必须使用 DECIMAL 替代 FLOAT 和 DOUBLE；
原因：在存储的时候，FLOAT 和 DOUBLE 都存在精度损失的问题，很可能在比较值的时候，得到不正确的结果。
1.8、尽可能不使用 TEXT、BLOB 类型；
原因：会浪费更多的磁盘和内存空间，非必要的大量大字段查询会淘汰掉热数据，导致内存命中率急剧降低，影响数据库性能。如果实在有某个字段过长需要使用 TEXT、BLOB 类型，则建议独立出来一张表，用主键来对应，避免影响原表的查询效率。
1.9、禁止在数据库中存储明文密码；
1.10、索引设计规范：
a、需要添加索引的字段
b、单表索引建议控制在 5 个以内；
c、适当配置联合索引；
比如方便查询能走覆盖索引，或者几个字段同时作为条件的概率很高时，当然还有其他很多种情况可以设置联合索引，具体可以复习第 13 节。
d、业务上具有唯一性的字段，添加成唯一索引；
遇到过几次字段在业务场景上要求唯一，但是该字段在数据库里的数据却出现了重复。因此在代码层考虑外，还需要在 MySQL 上的对应字段添加唯一索引。
e、在 varchar 字段上建立索引时，建议根据实际文本区分度指定索引长度；
原因：可以降低索引所占用的空间，并且很多时候，比如字符串基本是长度大于 20，但是只要建立长度为 20 的索引，就已经有很高的区分度了。可以使用 count(distinct left(列名, 索引长度))/count(*) 的区分度来确定。
f、索引禁忌：
- 不在低基数列上建立索引，例如：性别字段。
- 不在索引列进行数学运算和函数运算（原因，做函数操作可能会导致使用不了索引，具体可以复习第 4 节）
1.11、不建议使用外键；
原因：外键会导致表与表之间耦合，update 与 delete 操作都会涉及相关联的表，十分影响 sql 的性能，甚至会造成死锁。高并发情况下容易造成数据库性能。
1.12、禁止使用存储过程、视图、触发器、Event ；
原因：高并发的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性。
1.13、单表列数目建议小于 30；
自《一线数据库工程师带你深入理解 MySQL》
网友评论