修订记录
修订时间 |
修订后版本 |
发文号 |
修订部门 |
修订要点 |
2018-03-22 |
1.0版 |
研发部运维组：唐亚杰 |
创建 |
|
引言
1.1 背景及目的
本规范的目的是使本公司开发团队能以标准的、规范的方式设计和编码。通过建立编码规范，以使每个开发人员养成良好的编码风格和习惯；并以此形成开发小组编码约定，提高程序的可靠性、可读性、可修改性、可维护性和一致性等，增进团队间的交流，保证软件产品的质量。 。
1.2 适用范围
本规范适用于研发部所有开发人员、数据库运维DBA及开发DBA。
1.3 术语和缩略语
序号 |
术语/缩略语 |
全称和说明 |
1 |
表(TABLE) |
数据库中用于存储数据的基本逻辑单位 |
2 |
派生授权 |
给用户授权时，不使用with grant option |
1.4 数据库对象命名规范
1、 库名、表名、字段名禁止超过32个字符
2、数据库、表、字段等所有名称的可用字符范围为：A-Z，a-z， 0-9 和_下划线，除此外不允许使用其它字符作为名称
3、库名、表名、字段名用英文全称表达对应的含义，全称过长时可适当缩写，单词之间统一用 _ 间隔
4、表名应使用 项目名称_表名 的命名规则，清晰得分别表是属于哪个项目或子系统的
5、表名、字段名不应该使用数据库内定义的关键字，如：SELECT、FROM 等
6、查询多个字段和多个表关联时一定要使用列别名和表别名
7、所有表的业务类型数据一致的字段应使用相同的字段名和数据类型、字段长度一致
8、存储过程统一使用 “sp_存储过程名” 的命名规则， 函数统一使用 “fn_函数名” 的命名规则
9、存储过程和函数入参使用 pi_xxx, po_xxx 分别代表入参和出参的命名规则
1.5 MySQL表设计规范
1、每张表必须要有主键，默认字段为ID，数据类型选择自增 BIGINT UNSIGNED
2、分布式数据库主键不能使用自增主键，可使用Redis、snowflake服务、UUID_SHORT() 提高高性能的无锁机制的主键ID
3、多表中的相同列，必须保证列定义一致，避免多表相同字段产生歧义
4、默认使用InnoDB存储引擎，禁止使用Myiasm存储引擎
5、表字符集默认使用utf-8
6、表必须包含create_time和update_time字段，即表必须包含记录创建时间和修改时间的字段
7、单表一到两年内数据量超过500w或数据容量超过10G考虑分表，且需要提前考虑历史数据迁移或应用自行删除历史数据
8、尽量减少查询关联表的数量，控制3张表以下，关联字段需要建立索引
9、每个表必须有表级和字段级的注释，字段级的注释值较少的情况下应一一说明，比如：status字段， 0， 1， 2 要分别添加在注释
10、字段取名不应该与MySQL内部关键字相冲突
11、禁止使用Varchar字段作为主键，比如UUID()函数生成的唯一值
12、需要建立适当的冗余字段以便提高多表大表查询的性能，不能完全遵循第三范式
1.6 约束设计规范
1、业务上有非空约束应创建非空约束保障数据一致性
2、业务上默认值字段的应使用默认值，并增加非空约束
3、禁止使用外键约束，外键约束通过业务代码保障数据一致性
4、业务有字段值唯一需求的应使用唯一约束，复合唯一约束的慎重选择前置列，查询次数多的、选择性强的字段做为前置列
5、每张表都需要有主键，业务上有主键字段的优先选择业务主键，否则选择无业务性的自增ID主键
1.7 数据类型设计规范
1.7.1、整数型类型选择
|
类型
|
大小
|
范围（有符号）
|
范围（无符号）
|
用途
|
|---|---|---|---|---|
| TINYINT | 1 字节 | (-128，127) | (0，255) | 小整数值 |
| SMALLINT | 2 字节 | (-32 768，32 767) | (0，65 535) | 大整数值 |
| MEDIUMINT | 3 字节 | (-8 388 608，8 388 607) | (0，16 777 215) | 大整数值 |
| INT或INTEGER | 4 字节 | (-2 147 483 648，2 147 483 647) | (0，4 294 967 295) | 大整数值 |
| BIGINT | 8 字节 | (-9 233 372 036 854 775 808，9 223 372 036 854 775 807) | (0，18 446 744 073 709 551 615) | 极大整数值 |
整数类型选择原则：
1、尽量使用存储空间小的数据类型，比如状态字段应选择TINYINT数据类型
2、业务上无负数数据要求的使用无符号的数据类型，例如交易金额字段应优先选择：MEDIUMINT ZEROFILL
3、除自增ID外，应慎重选择BIGINT数据类型
1.7.2、浮点类型选择
|
类型
|
大小
|
范围（有符号）
|
范围（无符号）
|
用途
|
|---|---|---|---|---|
| FLOAT | 4 字节 | (-3.402 823 466 E+38，-1.175 494 351 E-38)，0，(1.175 494 351 E-38，3.402 823 466 351 E+38) | 0，(1.175 494 351 E-38，3.402 823 466 E+38) | 单精度 浮点数值 |
| DOUBLE | 8 字节 | (-1.797 693 134 862 315 7 E+308，-2.225 073 858 507 201 4 E-308)，0，(2.225 073 858 507 201 4 E-308，1.797 693 134 862 315 7 E+308) | 0，(2.225 073 858 507 201 4 E-308，1.797 693 134 862 315 7 E+308) | 双精度 浮点数值 |
| DECIMAL | 对DECIMAL(M,D) ，如果M>D，为M+2否则为D+2 | 依赖于M和D的值 | 依赖于M和D的值 | 小数值 |
浮点型数据类型选择原则：
1、对精度无要求的可以使用FLOAT和DOUBLE， 根据业务绝对优先选择FLOAT型，因为计算效率比DECIMAL高
2、对精度零丢失的业务数据需要使用DECIMAL数据类型，精度根据业务来严格控制，整型的必须选择整数类型不能选择此类型
1.7.3、时间类型选择
|
类型
|
大小
(字节) |
范围
|
格式
|
用途
|
|---|---|---|---|---|
| DATE | 3 | 1000-01-01/9999-12-31 | YYYY-MM-DD | 日期值 |
| TIME | 3 | '-838:59:59'/'838:59:59' | HH:MM:SS | 时间值或持续时间 |
| YEAR | 1 | 1901/2155 | YYYY | 年份值 |
| DATETIME | 8 | 1000-01-01 00:00:00/9999-12-31 23:59:59 | YYYY-MM-DD HH:MM:SS | 混合日期和时间值 |
| TIMESTAMP | 4 | 1970-01-01 00:00:00/2038-01-19 03:14:07
|
YYYYMMDD HHMMSS | 混合日期和时间值，时间戳 |
时间类型选择原则：
1、优先选择存储空间小的数据类型
2、create_time、update_time等应选择TIMESTAMP，不能选择DATETIME
3、在不能选择TIMESTAMP的业务场景才能选择DATETIME
4、业务上只存储年份、日期、时间的只能选择YEAR、DATE、TIME，不能使用DATETIME替代
1.7.4、字符串类型选择
|
类型
|
大小
|
用途
|
|---|---|---|
| CHAR | 0-255字节 | 定长字符串 |
| VARCHAR | 0-65535 字节 | 变长字符串 |
| TINYTEXT | 0-255字节 | 短文本字符串 |
| TEXT | 0-65 535字节 | 长文本数据 |
| MEDIUMTEXT | 0-16 777 215字节 | 中等长度文本数据 |
| LONGTEXT | 0-4 294 967 295字节 | 极大文本数据 |
字符串类型选择原则：
1、优先选择存储空间小的数据类型
2、禁止使用CHAR数据类型，应使用VARCHAR代替
3、TINYTEXT和TEXT请使用VARCHAR类型代替
4、根据业务尽量选择MEDIUMTEXT，谨慎使用LONGTEXT
1.8 索引设计规范
1、只在需要建立索引的字段建立索引，比如：筛选字段、被关联字段、排序字段、分组字段等建立索引， 不需要建立索引的字段不能建立多余索引
2、索引列的分布基数越大索引效果越好，所以能建立唯一索引尽量使用唯一索引
3、不在基数很小的字段建立索引，比如 type、sex字段等
4、不能在索引字段使用处理函数或表达式，因为这种操作会导致索引失效
5、过滤字段的传入值应该保持与字段的数据类型一致，关联字段应使用相同的数据类型，避免因隐式转换导致索引失效
6、不能在相同的字段重复建立冗余的索引
7、Like操作前模糊匹配，比如： like '%keyword%' 、 like '%keyword' 会导致索引失效，有此类操作且数据量很大要使用搜索引擎代替
8、建立复合索引时，基数大的字段和经常查询的字段应该放在最前面，MySQL没有Oracle的跳跃式索引扫描
9、尽量使用短索引，如果 varchar(200) 前20个字符就能唯一确定值的唯一了那就使用前20个字符建立就好了，短索引的存储空间比普通索引小，查询效率和存储效率更高
1.9 SQL编写规范
1、查询语句应使用统一的格式，如：数据库关键字大写，字段名和表名小写，关键字直接换行并缩进两个空格
2、尽量避免子查询，如： FROM子句中的子查询可以坚决避免使用， WHERE子句中的子查询可以使用表关联代替，SELECT子句中子查询一定要在分页完之后才能使用
3、尽量控制查询时表关联降低到3个以下，提升查询效率
4、查询分区表时，尽量都带上分区键的过滤字段
5、要善于使用 Case When 进行复杂分组查询统计操作，提升查询性能
6、禁止在业务SQL中使用更新操作表超过1W条记录的SQL，有此类操作应该分批提交
7、对单表的多次alter修改表操作，应合在一个SQL中执行
8、有临时大量数据的存储需求时，应使用数据库的临时表，禁止使用普通堆表代替临时表
9、禁止使用SELECT * 操作
10、！= 查询操作无法使用到索引，尽量修改成 = 操作
11、左关联查询记录数时，不在过滤条件的表不能关联查询