数据库使用规范

ps：数据库规范对于任何的行业都不具备统一性，一切的数据库规范都应该根据企业实际情况出发。

数据库基础设置

1. 必须使用InnoDB存储引擎

说明：持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高。

1. 建议使用utf8mb4编码

说明：万国码，无需转码，无乱码风险，节省空间，utf8mb4是utf8的超集，由于近年移动设备的增多，emoji表情以及部分不常见汉字在utf8下会表现为乱码。

1. 控制单表数量，对于高并发（100）量的单表数据不宜超过300w，对于低并发的不宜超过1000w。或者容量超过 2GB，推荐进行分库分表，如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表
2. 根据业务情况，考虑使用合适的隔离级别

建表字段设计规范

命名规范

1. 库名、表名、字段名：小写，下划线风格， 禁止出现数字开头，禁止两个下划线中间只出现数字，不超过32个字符，禁止拼音英文混用，见名能知其意。表的命名最好是加上“业务名称_表的作用”
2. 表、字段须加有中文注释
3. 日志表查询结尾统一为“_log”，查询日志表必须要带有日期条件，需要查询的日志表，对时间建立索引，减少数据库压力;

数据类型规范

1. varchar长度不得超过2000。

说明：varchar是变长的数据类型，仅使用必要的数据空间，同时需要额外的空间存储长度。在数据产生变更时，容易产生页分裂。

1. 使用varchar时，长度尽可能接近实际长度。

说明：varchar在硬盘中是变长，而读取到内存则是定长，临时表同理，与varchar(5)相比varchar(200)的长度无疑更消耗性能。

1. char适合存储非常短的字符串，或者长度几乎一致的字符串（md5）。而varchar则能满足大部分的要求。
2. 表示是否的子字段，采用tinyint类型，命名规则为is_xxx。
3. 必须把字段定义为NOT NULL并且提供默认值

说明：

a)mysql对于null的值要做多余的特殊处理，对性能有影响。

b)对null的处理时候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、 not in这些操作符号。

c)当某一列的值全是 NULL 时，count(col)的返回结果为 0，但 sum(col)的返回结果为 NULL,count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1, col2) 如果其中一列全为NULL，那么即使另一列有不同的值，也返回为0

1. 禁止使用TEXT、BLOB类型，必须text字段需独立出一张表。
2. 单表字段数上限尽量控制在20到50 个。

索引规范

1. 禁止在更新十分频繁、区分度不高的属性上建立索引。
2. 尽可能将单列索引合并成组合索引，单表索引建议控制在7个以内。

说明：在数据插入，删除，更新的时候，如果索引过多，重建索引的时间开销变大

1. 联合索引需要遵守最左前缀法则，所以组合索引根据sql的具体情况，确定建立索引的字 段顺序。将经常使用的，能进行快速区分的字段排在前面。（下文有最左前缀法则的一句概括）
2. 联合索引字段不要超过5个

说明：字段超过5个时，实际已经起不到有效过滤数据的作用了

1. 业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引

说明：不要以为唯一索引影响了 insert速度，这个速度损耗可以忽略，但提高查找速 度是明显的 ；

1. 在 varchar 字段上建立索引时，建议可以指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。

说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引， 区分度会高达 90%以上，可以使用 count(distinct left( 列名, 索引长度 )) / count( * ) 的 区分度来确定。

1. 如果有 order by 的场景，请注意利用索引的有序性。 order by 最后的