数据库设计规范

注：部分参考来源于网络

1.命名规范

1.【强制】库的名称必须控制在32个字符以内，相关模块的表名与表名之间尽量提现join的关系，如user表和user_login表。

2.【强制】库的名称格式：业务系统名称_子系统名，同一模块使用的表名尽量使用统一前缀，如wll_manage

3.【强制】一般分库名称命名格式是库通配名_编号，编号从0开始递增，比如wll_001；以时间进行分库的名称格式是“库通配名_时间”。

4.【强制】创建数据库时必须显式指定字符集，并且字符集只能是utf8mb4。创建数据库SQL举例：create database db1 default character set utf8mb4;由于政府行业面向的用户群体，禁止使用utf8；

5.【建议】表名要清晰；

6.【建议】字段命名要符合规范，同时语义清晰；

7.【强制】每个字段要有对应的comment描述，尽量清晰,表名必须带注释；

带有注释的表结构有助于后期人员维护和代码生成器根据表结构生成代码中带有正确的注释说明

8.【建议】为了多类型数据库兼容性，字段命名尽量避免数据库关键字，例如达梦数据库中table,list,comment,column,end作为字段名，查询时需要加双引号来处理，而mysql中双引号会被当做字符串，table,column在mysql中也需要改成`table`，`column`才能查询，但是这个单引号在达梦数据库中不兼容，从而导致不得不另外做兼容处理

2.结构设计规范

1.【强制】表和列的名称必须控制在32个字符以内，表名只能使用字母、数字和下划线，一律小写。禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。

说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库

名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。

正例：aliyun_admin，rdc_config，level3_name

反例：AliyunAdmin，rdcConfig，level_3_name

2.【强制】表名要求模块名强相关，如师资系统采用”sz”作为前缀，渠道系统采用”qd”作为前缀等。

3.【强制】创建表时必须显式指定字符集为utf8mb4。

4.【强制】创建表时必须显式指定表存储引擎类型，如无特殊需求，一律为InnoDB。

当需要使用除InnoDB/MyISAM/Memory以外的存储引擎时，必须通过DBA审核才能在生产环境中使用。因为Innodb表支持事务、行锁、宕机恢复、MVCC等关系型数据库重要特性，为业界使用最多的MySQL存储引擎。而这是其他大多数存储引擎不具备的，因此首推InnoDB。无对指定引擎的特殊依赖，禁止使用InnoDB以外的数据库存储引擎；

5.【强制】建表必须有comment；
6.【建议】建表时关于主键：

(1)强制要求主键为id，类型为int或bigint，且为auto_increment；

(2)标识表里每一行主体的字段不要设为主键，建议设为其他字段如user_id，order_id等，并建立unique key索引。因为如果设为主键且主键值为随机插入，则会导致innodb内部page分裂和大量随机I/O，性能下降。主键id没有任务业务意义，在业务代码中不得使用主键id用于查询条件。唯一索引的业务ID在业务表设计中可以使用，对于字典项类的表可以无此字段；

7.【建议】业务相关表（如用户表，金钱相关的表）必须有行数据的创建时间字段create_time和最后更新时间字段update_time，便于查问题。

8.【建议】表中所有字段必须都是NOT NULL属性，业务可以根据需要定义DEFAULT值。因为使用NULL值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题。

9.【建议】建议对表里的blob、text等大字段，垂直拆分到其他表里，仅在需要读这些对象的时候才去select。

10.【建议】反范式设计：把经常需要join查询的字段，在其他表里冗余一份。如user_name属性在user_account，user_login_log等表里冗余一份，减少join查询。
11.【强制】中间表用于保留中间结果集，名称必须以tmp_开头。备份表用于备份或抓取源表快照，名称必须以bak_开头。中间表和备份表定期清理。
【强制】对于超过100W行的大表进行alter table，必须经过DBA审核，并在业务低峰期执行。因为alter table会产生表锁，期间阻塞对于该表的所有写入，对于业务可能会产生极大影响。建议停服进行更新，避免引起数据库故障导致业务恢复困难。
12.【建议】能使用数子类型的字段建议使用数字类型而不是字符串类型，因为匹配字符串是一个字符一个字符的比对，效率比数字的低
13.【建议】字段的定义必须指定相应的长度，避免空间的浪费，布尔类型定义为tinnyint( 1 )，普通枚举类型值定义为tinnyint( 4bi'x )，例如delete字段应设置为tinnyint( 1 ),user_type 为tinnyint( 2 )

14.【建议】对于字符长度超过4000的字段应该使用长文本类型，例如text,longbob等，不应使用vachar类型，低版本上会报错，而且会影响查询效率

15.【建议】所有字段都设置为NOT NULL,不建议使用NULL设置，如果不需要用户填写的，字符串默认为‘’，数字默认为0或-1， 优点有以下几点

  1）节省空间，NULL 列需要更多的存储空间：需要一个额外字节作为判断是否为 NULL 的标志位
  2）减少因为空值而出现的计算错误，count(NULL column) 需要格外注意，NULL 值不会参与统计
  3）含有空值的列很难进行查询优化，而且对表索引时不会存储 NULL 值的
  4）NOT IN 、!= 等负向条件查询在有 NULL 值的情况下，返回永远为空结果，查询容易出错。

16.【推荐】对于并发要求比较高，频繁更改字段的表应该增加version版本自增字段来保证幂等性
17.【推荐】只涉及插入的表，例如日志表，需要增加creator_id,create_time,普通的表应增加creator_id,create_time，updater_id，update_time，deleted字段
18.【推荐】对于重要的数据，不建议使用强删除，应该使用deleted字段来控制

19. 【强制】表名不使用复数名词。

说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数

形式，符合表达习惯。

20. 【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。

21. 【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。

22. 【推荐】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：

1）不是频繁修改的字段。

2）不是 varchar 超长字段，更不能是 text 字段。

正例：商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存

储类目名称，避免关联查询。

23. 【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

24. 【推荐】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检

索速度。

正例：如下表，其中无符号值可以避免误存负数，且扩大了表示范围。

3.索引设计规范

1.【强制】InnoDB表必须主键为id int/bigint auto_increment,且主键值禁止被更新。
2.【建议】主键的名称以“pk_”开头，唯一键以“uk_”或“uq_”开头，普通索引以“idx_”开头，一律使用小写格式，以表名/字段的名称或缩写作为后缀。
3.【强制】InnoDB和MyISAM存储引擎表，索引类型必须为BTREE；MEMORY表可以根据需要选择HASH或者BTREE类型索引。
4.【强制】单个索引中每个索引记录的长度不能超过64KB。
5.【建议】单个表上的索引个数不能超过7个。
6.【建议】在建立索引时，多考虑建立联合索引，并把区分度最高的字段放在最前面。如列userid的区分度可由select count(distinct userid)计算出来。
7.【建议】在多表join的SQL里，保证被驱动表的连接列上有索引，这样join执行效率最高。

8.【建议】建表或加索引时，保证表里互相不存在冗余索引。对于MySQL来说，如果表里已经存在key(a,b)，则key(a)为冗余索引，需要删除。
9.【强制】对于匹配度不高的字段禁止建立单个索引，例如delete字段只有0和1两个值
10.【建议】关联表不建议建立外键关联索引，应该改用代码逻辑上进行控制，外键索引会降低插入更新删除的执行效率，而且分库分表的情况下会出现无法跨库检查外键表索引而导致执行失败的情况

11. 【强制】超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询时，保证被关联的字段需要有索引。

说明：即使双表 join 也要注意表索引、SQL 性能。

12. 【强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据

实际文本区分度决定索引长度即可。

说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分阿里巴巴 Java 开发手册

度会高达 90%以上，可以使用 count( distinct left ( 列名, 索引长度 ) )/count( * )的区分度

来确定。

13. 【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。

说明：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

14. 【建议】如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。

正例：where a=? and b=? order by c; 索引：a_b_c

反例：索引中有范围查找，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引

a_b 无法排序。

15. 【建议】利用覆盖索引来进行查询操作，避免回表。

说明：如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览

一下就好，这个目录就是起到覆盖索引的作用。

正例：能够建立索引的种类：主键索引、唯一索引、普通索引，而覆盖索引是一种查询的一种

效果，用 explain 的结果，extra 列会出现：using index。

16. 【建议】利用延迟关联或者子查询优化超多分页场景。

说明：MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回

N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过

特定阈值的页数进行 SQL 改写。

正例：先快速定位需要获取的 id 段，然后再关联：

SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

17. 【建议】SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts

最好。

说明：

1）consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。

2）ref 指的是使用普通的索引（normal index）。

3）range 对索引进行范围检索。

反例：explain 表的结果，type=index，索引物理文件全扫描，速度非常慢，这个 index 级

别比较 range 还低，与全表扫描是小巫见大巫。

18. 【建议】建组合索引的时候，区分度最高的在最左边。

正例：如果 where a=? and b=? ，a 列的几乎接近于唯一值，那么只需要单建 idx_a 索引即

可。

说明：存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置。如：where a>?

and b=? 那么即使 a 的区分度更高，也必须把 b 放在索引的最前列。

19. 【建议】防止因字段类型不同造成的隐式转换，导致索引失效。

20. 【建议】创建索引时避免有如下极端误解：

1）宁滥勿缺。认为一个查询就需要建一个索引。

2）宁缺勿滥。认为索引会消耗空间、严重拖慢更新和新增速度。

3）抵制惟一索引。认为业务的惟一性一律需要在应用层通过“先查后插”方式解决。

21.【建议】唯一索引联合唯一索引,不应该建立在有null值得列,或者避免出现null值

  在mysql和Oracle中,根据NULL的定义，NULL表示的是未知，因此两个NULL比较的结果既不相等，也不不等，结果仍然是未知。根据这个定义，多个NULL值的存在应该不违反唯一约束，所以是合理的,然而在sqlserver 和达梦数据库中,null值也不允许重复,所以确保唯一性,不建议在允许列值为null的列建立唯一索引或联合唯一索引

4.SQL 语句

1. 【强制】不要使用 count( 列名 )或 count( 常量 )来替代 count( * )，count( * )是 SQL92 定义的

标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。

说明：count( * )会统计值为 NULL 的行，而 count( 列名 )不会统计此列为 NULL 值的行。

2. 【强制】count( distinct col ) 计算该列除 NULL 之外的不重复行数，注意 count(distinct

col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。

3. 【强制】当某一列的值全是 NULL 时，count( col )的返回结果为 0，但 sum( col )的返回结果为

NULL，因此使用 sum()时需注意 NPE 问题。

正例：可以使用如下方式来避免 sum 的 NPE 问题：SELECT IF ( ISNULL ( SUM ( g ) ),0,SUM ( g ))

FROM table;

4. 【强制】使用 ISNULL()来判断是否为 NULL 值。

说明：NULL 与任何值的直接比较都为 NULL。

1） NULL<>NULL 的返回结果是 NULL，而不是 false。

2） NULL=NULL 的返回结果是 NULL，而不是 true。

3） NULL<>1 的返回结果是 NULL，而不是 true。

5. 【强制】在代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句。

6. 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

说明：以学生和成绩的关系为例，学生表中的 student_id是主键，那么成绩表中的 student_id

则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为

级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻

塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。

7. 【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

8. 【强制】数据订正时，删除和修改记录时，要先 select，避免出现误删除，确认无误才能执

行更新语句。

9. 【建议】in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控

制在 1000 个之内。

10. 【建议】如果有全球化需要，所有的字符存储与表示，均以 utf-8 编码，注意字符统计函数的区别。

说明：

SELECT LENGTH("轻松工作")； 返回为 12

SELECT CHARACTER_LENGTH("轻松工作")； 返回为 4

如果需要存储表情，那么选择 utfmb4 来进行存储，注意它与 utf-8 编码的区别。

11. 【建议】TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但 TRUNCATE无事务且不触发 trigger，有可能造成事故，故不建议在开发代码中使用此语句。

说明：TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。

5.ORM 映射

1.【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。

说明：1）增加查询分析器解析成本。2）增减字段容易与 resultMap 配置不一致。

2. 【强制】POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行

字段与属性之间的映射。

说明：参见定义 POJO 类以及数据库字段定义规定，在<resultMap>中增加映射，是必须的。

在 MyBatis Generator 生成的代码中，需要进行对应的修改。

3. 【强制】不要用 resultClass 当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义；反过来，每一个表也必然有一个与之对应。

说明：配置映射关系，使字段与 DO 类解耦，方便维护。

4. 【强制】sql.xml 配置参数使用：#{}，#param# 不要使用${} 此种方式容易出现 SQL 注入。

5. 【强制】iBATIS 自带的 queryForList(String statementName,int start,int size)不推

荐使用。

说明：其实现方式是在数据库取到statementName对应的SQL语句的所有记录，再通过subList

取 start,size 的子集合。

正例：Map<String, Object> map = new HashMap<String, Object>();

map.put("start", start);

map.put("size", size);

6. 【强制】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输出。

说明：resultClass=”Hashtable”，会置入字段名和属性值，但是值的类型不可控。

7. 【强制】更新数据表记录时，必须同时更新记录对应的 gmt_modified 字段值为当前时间。

8. 【建议】不要写一个大而全的数据更新接口。传入为 POJO 类，不管是不是自己的目标更新字段，都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL时，不要更新无改动的字段，一是易出错；二是效率低；三是增加 binlog 存储。

9. 【建议】@Transactional 事务不要滥用。事务会影响数据库的 QPS，另外使用事务的地方需要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。

10. 【建议】<isEqual>中的 compareValue 是与属性值对比的常量，一般是数字，表示相等时带

上此条件；<isNotEmpty>表示不为空且不为 null 时执行；<isNotNull>表示不为 null 值时

执行。

6.安全设计规范

1 【强制】禁止复杂sql语句

在mysql作为业务数据库时，不得写出来特别复杂的sql语句（如嵌套、多于3张表的join操作、where里多种函数引用等）；对于业务场景比较复杂的需要拆分为简单sql语句，有业务代码多次请求，避免因为语句过于复杂引起索引失效、锁表等问题。

2 【强制】自增主键id禁止传递给前端

在当前规范下，主键id不得用于业务使用，不能作为属性值传递给前端，避免被抓包后遍历，导致数据泄露；避免前端有基于自增主键的操作，采用唯一索引。

3.【强制】三要素信息（姓名、手机号、身份证号）必须单独建表并加密保存，所以业务表只能基于外键关联，不得冗余三要素信息；查询后业务方解密使用时，禁止明文传递，必须脱敏处理（姓名保留首尾，身份证号隐藏中间年月日，手机号隐藏中间四位，具体脱敏程度根据业务方要求可以更严格）

4.【建议】其他敏感信息建议加密存储或脱敏存储；

5.【建议】避免使用拼接语句的查询语句，无法避免的情况下可使用concat连接字来拼接和对敏感字符进行去除特殊字符处理

6.【建议】对于敏感信息，如果不需要作为条件匹配查询，优先考虑带偏移量的aes或rsa加密，作为条件查询的可更改为指定偏移量的aes加密来保证加密的结果一致。
7.【建议】对于密码等无须解密处理的字段优先使用md5+salt的方式加密

7.SQL查询注意事项

1. 注意时间格式化的中,M和m,H和h的区别

例如 SELECT  DATE_FORMAT('2022-07-22 17:00:00', '%Y-%c-%d %h:%i' ) 返回的是2022-7-22 05:00, SELECT  DATE_FORMAT('2022-07-22 17:00:00', '%Y-%c-%d %H:%i' ) 返回的是2022-7-22 17:00,使用时间比较会出现问题