背景
因为工作岗位的起因，负责制订了对于后端组数据库的规约标准，作为所有产品线的标准，历经几版的批改，最终造成下边的文本。
标准在整个后端执行也有大半年的工夫，对于整个团队在开发阶段就缩小不失当的建表语句、谬误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 NULL并且提供默认值
解读：
- NULL的列使索引/索引统计/值比拟都更加简单，对MySQL来说更难优化；
- NULL这种类型Msql外部须要进行非凡解决，减少数据库解决记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的解决性能会升高很多；
- NULL值须要更多的存储空，无论是表还是索引中每行中的NULL的列都须要额定的空间来标识。
【强制】（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）禁止应用外键与级联，所有外键概念必须在应用层解决
解读：外键与级联更新实用于单机低并发，不适宜分布式、高并发集群;级联更新是强阻塞，存在数据库更新风暴的危险；外键影响数据库的插入速度。
【倡议】（6）应尽量避免在WHERE子句中应用or作为连贯条件
解读：依据状况能够抉择应用UNION ALL来代替OR。
【强制】（7）不容许应用%结尾的含糊查问
解读：依据索引的最左前缀原理，%结尾的含糊查问无奈应用索引，能够应用ES来做检索。
三、索引规约
【倡议】（1）防止在更新比拟频繁、区分度不高的列上独自建设索引
解读：区分度不高的列独自创立索引的优化成果很小，然而较为频繁的更新则会让索引的保护老本更高。
【强制】（2） JOIN的表不容许超过五个。须要JOIN的字段，数据类型必须相对统一; 多表关联查问时，保障被关联的字段须要有索引
解读：太多表的JOIN会让Mysql的优化器更难衡量出一个“最佳”的执行打算（可能性为表数量的阶乘），同时要留神关联字段的类型、长度、字符编码等等是否统一。
【强制】（3）在一个联结索引中，若第一列索引区分度等于1，那么则不须要建设联结索引
解读：索引通过第一列就可能齐全定位的数据，所以联结索引的后边局部是不须要的。
【强制】（4）建设联结索引时，必须将区分度更高的字段放在右边
解读：区分度更高的列放在右边，可能在一开始就无效的过滤掉无用数据。进步索引的效率，相应咱们在Mapper中编写SQL的WHERE条件中有多个条件时，须要先看看以后表是否有现成的联结索引间接应用，留神各个条件的程序尽量和索引的程序统一。
【倡议】（5）利用笼罩索引来进行查问操作，防止回表
解读：笼罩查问即是查问只须要通过索引即可拿到所需DATA，而不再须要再次回表查问，所以效率绝对很高。咱们在应用EXPLAIN的后果，extra列会呈现："using index"。这里也要强调一下不要应用“SELECT * ”，否则简直不可能应用到笼罩索引。
【倡议】（6）在较长VARCHAR字段,例如VARCHAR(100)上建设索引时，应指定索引长度，没必要对全字段建设索引，依据理论文本区分度决定索引长度即可
解读：索引的长度与区分度是一对矛盾体，个别对字符串类型数据，若长度为20的索引，区分度会高达90%以上，则能够思考创立长度例为20的索引，而非全字段索引。例如能够应用SELECT COUNT(DISTINCT LEFT(lesson_code, 20)) / COUNT(*) FROM lesson;来确定lesson_code字段字符长度为20时文本区分度。
【倡议】（7）如果有ORDER BY的场景，请留神利用索引的有序性。ORDER BY最初的字段是联结索引的一部分，并且放在索引组合程序的最初，避免出现file_sort的状况，影响查问性能。
解读：
- 假如有查问条件为WHERE a=? and b=? ORDER BY c；存在索引：a_b_c，则此时能够利用索引排序；
- 反例：在查问条件中蕴含了范畴查问，那么索引有序性无奈利用，如:WHERE a>10 ORDER BY b; 索引a_b无奈排序。
【倡议】（8）在where中索引的列不能某个表达式的一部分，也不能是函数的参数
解读：即是某列上曾经增加了索引，然而若此列成为表达式的一部分、或者是函数的参数，Mysql无奈将此列独自解析进去，索引也不会失效。
【倡议】 （9）咱们在where条件中应用范畴查问时，索引最多用于一个范畴条件，超过一个则后边的不走索引
解读：Mysql可能应用多个范畴条件里边的最右边的第一个范畴查问，然而后边的范畴查问则无奈应用。
【倡议】 （10）在多个表进行外连贯时，表之间的关联字段类型必须完全一致
解读：当两个表进行Join时，字段类型若没有完全一致，则加索引也不会失效，这里的完全一致包含但不限于字段类型、字段长度、字符集、collection等等。
>>>>
参考资料
- 《High.Performance.MySQL.3rd.Edition》
- 《阿里巴巴java开发手册》
作者丨浮雷
起源丨https://juejin.im/post/687196...
关注Java编程鸭微信公众号，后盾回复：码农大礼包 能够获取最新整顿的技术材料一份。涵盖Java 框架学习、架构师学习等！