建议收藏 - 专业的MySQL开发规范

为了项目的稳定，代码的高效，管理的便捷，在开发团队内部会制定各类各样的规范

这里分享一份咱们定义的MySQL开发规范，欢迎交流拍砖

数据库对象命名规范

数据库对象

命名规范的对象是指数据库SCHEMA、表TABLE、索引INDEX、约束CONSTRAINTS等的命名约定

数据库对象命名原则

1. 命名使用具备意义的英文词汇，词汇中间如下划线分隔
2. 命名只能使用英文字母、数字、下划线
3. 避免用MySQL的保留字如：call、group等
4. 全部数据库对象使用小写字母

数据库命名规范

1. 数据库名不能超过30个字符
2. 数据库命名必须为项目英文名称或有意义的简写
3. 数据库建立时必须添加默认字符集和校对规则子句。默认字符集为UTF8(已迁移dumbo的使用utf8mb4)
4. 命名应使用小写

表命名规范

1. 同一个模块的表尽量使用相同的前缀，表名称尽量表达含义
2. 多个单词如下划线（_）分隔
3. 表名不能超过30个字符
4. 普通表名以t_开头，表示为table，命名规则为t_模块名（或有意义的简写）_+table_name
5. 临时表(运营、开发或数据库人员临时用做临时进行数据采集用的中间表)命名规则：加上tmp前缀和8位时间后缀（tmp_test_user_20181109）
6. 备份表（DBA备份用做保存历史数据的中间表）命名规则：加上bak前缀和8位时间后缀（bak_test_user_20181109）
7. 命名应使用小写

字段命名规范

1. 字段命名须要表示其实际含义的英文单词或简写，单词之间用下划线（_）进行链接
2. 各表之间相赞成义的字段必须同名
3. 字段名不能超过30个字符

用户命名规范

1. 生产使用的用户命名格式为 code_应用
2. 只读用户命名规则为 read_应用

数据库对象设计规范

存储引擎的选择

如无特殊需求，必须使用innodb存储引擎

字符集的选择

如无特殊要求，必须使用utf8或utf8mb4

表设计规范

1. 不一样应用间所对应的数据库表之间的关联应尽量减小，不容许使用外键对表之间进行关联，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性
2. 表设计的角度不该该针对整个系统进行数据库设计，而应该根据系统架构中组件划分，针对每一个组件所处理的业务进行数据库设计
3. 表必需要有PK
4. 一个字段只表示一个含义
5. 表不该该有重复列
6. 禁止使用复杂数据类型(数组,自定义等)
7. 须要join的字段(链接键),数据类型必须保持绝对一致，避免隐式转换
8. 设计应至少知足第三范式,尽可能减小数据冗余。一些特殊场景容许反范式化设计，但在项目评审时须要对冗余字段的设计给出解释
9. TEXT字段必须放在独立的表中,用PK与主表关联。如无特殊须要，禁止使用TEXT、BLOB字段
10. 须要按期删除(或者转移)过时数据的表,经过分表解决
11. 单表字段数不要太多，建议最多不要大于50个
12. MySQL在处理大表时，性能就开始明显下降，因此建议单表物理大小限制在16GB，表中数据控制在2000W内
13. 若是数据量或数据增加在前期规划时就较大，那么在设计评审时就应加入分表策略
14. 无特殊需求，严禁使用分区表

字段设计规范

1. INT：如无特殊须要，存放整型数字使用UNSIGNED INT型。整型字段后的数字表明显示长度
2. DATETIME：全部须要精确到时间(时分秒)的字段均使用DATETIME,不要使用TIMESTAMP类型
3. VARCHAR：全部动态长度字符串 所有使用VARCHAR类型,相似于状态等有限类别的字段,也使用能够比较明显表示出实际意义的字符串,而不该该使用INT之类的数字来代替；VARCHAR(N)，N表示的是字符数而不是字节数。好比VARCHAR(255)，能够最大可存储255个字符（字符包括英文字母，汉字，特殊字符等）。但N应尽量小，由于MySQL一个表中全部的VARCHAR字段最大长度是65535个字节，且存储字符个数由所选字符集决定。如UTF8存储一个字符最大要3个字节，那么varchar在存放占用3个字节长度的字符时不该超过21845个字符。同时，在进行排序和建立临时表一类的内存操做时，会使用N的长度申请内存。(如无特殊须要，原则上单个varchar型字段不容许超过255个字符)
4. TEXT:仅仅当字符数量可能超过20000个的时候,才可使用TEXT类型来存放字符类数据,由于全部MySQL数据库都会使用UTF8字符集。全部使用TEXT类型的字段必须和原表进行分拆,与原表主键单独组成另一个表进行存放。如无特殊须要，严禁开发人员使用MEDIUMTEXT、TEXT、LONGTEXT类型
5. 对于精确浮点型数据存储，须要使用DECIMAL，严禁使用FLOAT和DOUBLE
6. 如无特殊须要，严禁开发人员使用BLOB类型
7. 如无特殊须要，字段建议使用NOT NULL属性，可用默认值代替NULL
8. 自增字段类型必须是整型且必须为UNSIGNED，推荐类型为INT或BIGINT，而且自增字段必须是主键或者主键的一部分

索引设计规范

1. 索引必须建立在索引选择性选择性较高的列上,选择性的计算方式为: select count(distinct(col_name))/count(*) from tb_name;若是结果小于0.2，则不建议在此列上建立索引，不然大几率会拖慢SQL执行
2. 组合索引的首字段,必须在where条件中，对于肯定须要组成组合索引的多个字段,建议将选择性高的字段靠前放
3. 禁止使用外键
4. Text类型字段若是须要建立索引，必须使用前缀索引
5. 单张表的索引数量理论上应控制在5个之内。常常有大批量插入、更新操做表，应尽可能少建索引
6. ORDER BY，GROUP BY，DISTINCT的字段须要添加在索引的后面，造成覆盖索引
7. 尽可能使用Btree索引，不要使用其它类型索引

约束设计规范

1. PK应该是有序而且无心义的,尽可能由开发人员自定义,且尽量短，使用自增序列。
2. 表中除PK之外,还存在惟一性约束的,能够在数据库中建立以“uidx_”做为前缀的惟一约束索引。
3. PK字段不容许更新。
4. 禁止建立外键约束,外键约束由应用控制。
5. 如无特殊须要，全部字段必须添加非空约束，即not null。
6. 如无特殊须要，全部字段必须有默认值。

SQL编写规范

1. 尽可能避免使用select *，join语句使用select *可能致使只须要访问索引便可完成的查询须要回表取数
2. 严禁使用select * from table而不加任何where条件
3. MySQL中的text类型字段存储的时候不是和由其余普通字段类型的字段组成的记录存放在一块儿,并且读取效率自己也不如普通字段块。若是不须要取回text字段，又使用了select *,会让完成相同功能的sql所消耗的io量大不少,并且增长部分的io效率也更低下
4. 在取出字段上可使用相关函数，但应尽量避免出现now(),rand(),sysdate(),current_user()等不肯定结果的函数，在Where条件中的过滤条件字段上严禁使用任何函数，包括数据类型转换函数
5. 全部链接的SQL必须使用Join ... On ...方式进行链接，而不容许直接经过普通的Where条件关联方式。外链接的SQL语句,可使用Left Join On的Join方式，且全部外链接一概写成Left Join，而不要使用Right Join
6. 分页查询语句所有都须要带有排序条件,除非应用方明确要求不要使用任何排序来随机展现数据
7. WHERE条件中严禁在索引列上进行数学运算或函数运算
8. 用in()/union替换or，并注意in的个数小于300
9. 严禁使用%前缀进行模糊前缀查询:如：select id,val from table where val like ‘%name’;可使用%模糊后缀查询如：select id,val from table where val like ‘name%’
10. 严禁使用INSERT ON DUPLICATE KEY UPDATE、REPLACE INTO、INSERT IGNORE

---

相关文章推荐阅读：

• 运维效率之数据迁移自动化
• MySQL EXPLAIN结果集分析 - 附带大量案例