I 文档定义 1.1 编写目的
为了在软件生命周期内规范数据库相关的需求分析、设计、开发、测试、运维工作，便于不同团队之间的沟通协调，以及在相关规范上达成共识，提升相关环节的工作效率和系统的可维护性。同时好的规范，在执行的时候可以培养出好的习惯，好的习惯是软件质量的保证。
1.2 适用范围本文档适用于开发、测试、QA及运维团队成员。
II . 命名设计规范 2.1 总则（1）所有命名采用26个英文小写字母和0－9这十个自然数，加上下划线_组成。不能出现其他字符（注释除外）。
（2）对象名尽量短，长度不超过30个字符。
（3）对象名字尽量描述实体的内容，由英文单词、单词组合或单词缩写组成，不以数字和_开头。
（4）命名中禁止使用SQL保留字。
2.2 库名库名与应用名称尽量一致，统一小写，以下划线分割。
2.3 表名表名必须使用小写字母或数字，以下划线分割，禁止出现数字开头，禁止两个下划线中间只出现数字。如果表名仅有一个单词，那么建议不使用缩写，而是用完整的单词。同一模块的表尽可能使用相同的前缀，表名称尽可能表达含义。
数据表 <模块标识>_<表标识> 例如： order_header , order_detail
编码表 base_<模块标识>_<表标识>
日志表 log_<模块标识>_<表标识>
2.4 字段名（1） 能表达字段功能的英文单词或单词缩写，一般不超过三个英文单词，以下划线分割。布尔类型的字段以“is_”作为前缀。
（2） 各表之间意义相同的字段应同名。
（3） 系统中所有属于内码的字段（仅用于表示唯一性和程序内部用到的标识性字段），名称取为：<表标识>_id。
（4） 系统中属于是业务范围内的编号的字段，其代表一定的业务信息，这样的字段建议命名为<业务标识>_code，其数据类型为VARCHAR，该字段需加唯一索引。
（5） 字段名不要与表名重复。
（6） 不要在列的名称中包含数据类型。
（7） 每个字段添加字段说明。
（8） 数据库字段名的修改代价很大，所以字段名称需要慎重考虑。
（9） 统一命名字段：create_by、create_time、modify_by、modify_time、disabled
2.5 索引名A. 非唯一索引必须按照“idx_<构成索引的字段名>”进行命名
例如：在age上添加索引idx_age
B. 唯一索引必须按照“uidx_<构成索引的字段名>”进行命名
例如：uidx_cardid
C. 组合索引建议包含所有字段名，过长的字段名可以采⽤缩写形式
例如：idx_age_name
2.6 视图命名v_<模块标识>_<视图标识>
2.7 存储过程命名usp_<模块标识>_<存储过程标识>
2.8 函数命名ufn_<模块标识>_<函数标识>
III 数据库设计规范 3.1 表设计原则（1） 表的存储引擎建议是InnoDB存储引擎,InnoDB 支持事务，支持行级锁，更好的恢复性，高并发下性能更好
（2）同一个DB中的表，其存储引擎、字符集应保持统一
（2） 数据表创建、变更具备说明文档
数据表创建、变更时必须提供数据表设计文档: 包含表及字段详细说明
（3） 规范化与反规范化
规范化的优点是减少了数据冗余，节约了存储空间，相应逻辑和物理的I/O次数减少，同时加快了增、删、改的速度。但是一个完全规范化的设计并不总能生成最优的性能，因为对数据库查询通常需要更多的连接操作，从而影响到查询的速度，而且范式越高性能就会越差。出于性能和方便管理的考虑，原则上表设计应满足第三范式。有时为了提高某些查询或应用的性能而可以破坏规范规则，即反规范化。数据应当按两种类别进行组织：频繁访问的数据和频繁修改的数据。对于频繁访问但是不频繁修改的数据，内部设计应当物理不规范化。对于频繁修改但并不频繁访问的数据，内部设计应当物理规范化。比较复杂的方法是将规范化的表作为逻辑数据库设计的基础，然后再根据整个应用系统的需要，物理地非规范化数据。
（4）临时库表必须以 _tmp_ 为前缀并以日期为后缀，备份表必须以 _bak_ 为前缀并以日期 为后缀。
（5）尽量控制单表数据量的大小，建议控制在 600 万以内