超全的数据库建表/SQL/索引规范，适合贴在工位上背景因为工作岗位的原因

文章插图
背景
因为工作岗位的原因，负责制定了关于后端组数据库的规约规范，作为所有产品线的规范，历经几版的修改，最终形成下边的文本。
规范在整个后端执行也有大半年的时间，对于整个团队在开发阶段就减少不恰当的建表语句、错误SQL、错误的索引有积极的意义，故分享出来给大家参考。
下边分为建表规约、SQL规约、索引规约三个部分，每部分的每一条都有强制、建议两个级别，大家在参考时，根据自己公司的情况来权衡。
一、建表规约
【强制】（1）存储引擎必须使用InnoDB
解读：InnoDB支持事物、行级锁、并发性能更好， CPU及内存缓存页优化使得资源利用率更高。
【强制】（2）每张表必须设置一个主键ID ，且这个主键ID使用自增主键（在满足需要的情况下尽量短），除非在分库分表环境下
解读：由于InnoDB组织数据的方式决定了需要有一个主键，而且若是这个主键ID是单调递增的可以有效提高插入的性能，避免过多的页分裂、减少表碎片提高空间的使用率。而在分库分表环境下，则需要统一来分配各个表中的主键值，从而避免整个逻辑表中主键重复。
【强制】（3）必须使用utf8mb4字符集
解读：在Mysql中的UTF-8并非“真正的UTF-8” ，而utf8mb4”才是真正的“UTF-8” 。
【强制】（4）数据库表、表字段必须加入中文注释
解读：大家都别懒。
【强制】（5）库名、表名、字段名均小写，下划线风格，不超过32个字符，必须见名知意，禁止拼音英文混用
解读：约定。
【强制】（6）单表列数目必须小于30 ，若超过则应该考虑将表拆分
解读：单表列数太多使得Mysql服务器处理InnoDB返回数据之间的映射成本太高。
【强制】（7）禁止使用外键，如果有外键完整性约束，需要应用程序控制
解读：外键会导致表与表之间耦合， UPDATE与DELETE操作都会涉及相关联的表，十分影响SQL的性能，甚至会造成死锁。
【强制】（8）必须把字段定义为NOT 并且提供默认值
解读：

的列使索引/索引统计/值比较都更加复杂，对MySQL来说更难优化；
这种类型Msql内部需要进行特殊处理，增加数据库处理记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的处理性能会降低很多；
值需要更多的存储空，无论是表还是索引中每行中的的列都需要额外的空间来标识。

【强制】（9）禁用保留字，如DESC、RANGE、MARCH等，请参考Mysql官方保留字
【强制】（10）如果存储的字符串长度几乎相等，使用CHAR定长字符串类型。
解读：能够减少空间碎片，节省存储空间。
【建议】（11）在一些场景下，考虑使用TIMESTAMP代替DATETIME
解读：

这两种类型的都能表达"yyyy-MM-dd HH:mm:ss"格式的时间， TIMESTAMP只需要占用4个字节的长度，可以存储的范围为(1970-2038)年，在各个时区，所展示的时间是不一样的；
而DATETIME类型占用8个字节，对时区不敏感，可以存储的范围为(1001-9999)年。

* 【建议】（12）当心自动生成的Schema ，建议所有的Schema手动编写
解读：对于一些数据库客户端不要太过信任。
二、SQL规约
【建议】 (1) 为了充分利用缓存，不允许使用自定义函数、存储函数、用户变量
解读：如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、Mysql库中的系统表，其查询结果都不会被缓存。比如函数NOW或者CURRENT_DATE会因为不同的查询时间，返回不同的查询结果。
【强制】（2）在查询中指定所需的列，而不是直接使用“ *”返回所有的列
解读：

读取不需要的列会增加CPU、IO、NET消耗；
不能有效的利用覆盖索引。

【强制】（3）不允许使用属性隐式转换
解读：假设我们在手机号列上添加了索引，然后执行下面的SQL会发生什么？explain SELECT user_name FROM parent WHERE phone=13812345678; 很明显就是索引不生效，会全表扫描。
【建议】（4）在WHERE条件的属性上使用函数或者表达式
解读：Mysql无法自动解析这种表达式，无法使用到索引。
【强制】（5）禁止使用外键与级联，一切外键概念必须在应用层解决
解读：外键与级联更新适用于单机低并发，不适合分布式、高并发集群;级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。