数据库管理规范

数据库管理规范

数据库管理规范

版本号:V1、0

信息科 2017年4月

数据库管理规范

1 规范说明 .............................................................................................................................................. 1 2 维护管理安全规范 .............................................................................................................................. 1 3设计规范 ............................................................................................................................................... 2 4、 SQL编写规范 ................................................................................................................................. 5 5、 数据库备份与恢复策略规范 .......................................................................................................... 6 6开发测试与上线安全规范 ................................................................................................................... 7 7 监控 ...................................................................................................................................................... 7 8连接池使用规范 ................................................................................................................................... 8 9 数据库重要级别划分 .......................................................................................................................... 8 10 数据库安装规范 ................................................................................................................................ 8 11 业务上线数据库部分规范 ................................................................................................................ 9

1 规范说明

本规范就是针对数据库使用,维护管理,设计开发等。

2 维护管理安全规范

2、1数据库版本使用规范【强制】

MYSQL使用5、6、39社区版本

2、3数据库账户安全与管理规范

2、3、1 密码安全【强制】

? 密码不少于8位,应包含数字,字母,字符 ? 密码不应该与用户名一致

数据库管理规范

? 删除数据库默认空用户账户 ? 必须修改root密码

2、4账户安全管理【强制】

? ? ? ? ? ? ? ? ?

为应用程序设立独立访问账户

禁止开发工程师通过应用帐号登录生产数据库

禁止QA申请线上账号与使用账号登陆线上环境进行测试 数据库只有root用户具有最高管理权限

备份数据库用户要单独建立,并专属备份恢复操作 数据库安装后删除或锁闭不需要使用的数据库账号 数据库管理员账户可以锁定与解锁其她用户 数据库管理账户在空闲5分钟以上会自动退出 数据库管理权限账号不能超过2个

2、5数据库日志管理规范【强制】

windows、linux 下的日志管理

? Windows系统应开启日志功能,记录系统与系统中各个进程的相关信息 ? linux的操作系统要开启系统日志

? Mysql数据库如果使用了innodb引擎必须打开二进制日志 ? Mysql必须打开慢日志,并且将慢日志阀值设置为1-2秒之间 ? 对Mysql的错误日志等要进行定期查瞧,定期清理与定期备份管理

2、6数据库架构规范【强制】 2、6、1 mysql数据库高可用

? MYSQL 采用复制+第三方心跳软件或者第三方集群架构(经测试后)实现近7X24小时高

可用性要求,数据库架构必须能够实现故障自动迁移,满足业务7X24小时持续服务要求

3设计规范

3、1命名规范【强制】 3、1、1表的命名

表的名称在T_后增加一个或者多个后缀,表名、字段名必须使用小写字母或数字;禁止出现数字开头,禁止两个下划线中间只出现数字。数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。

3、1、2视图命名:V_相关表名(或者根据需要另取名字)

3、1、3存储过程命名:PRO_存储过程名(用英文表达存储过程意义) 3、1、4函数命名:FUN_函数名称(用英文表达函数作用)

3、1、5触发器命名:TRI_触发器名称(用英文表达触发器作用)

3、1、6索引命名:I_表名_字段名(如果存在多字段索引,取每字段前三个字符加下划线组合,如:在 hyid,hyname,hymobile上建立联合索引,命名:I_表名_hyi_hyn_hym,如果前三个截取字符相同,就从字段名称中不同的字符开始取三个字符加下划线组合,如:在 zhyid,zhyname,zhymobile上建立联合索引,命名:I_表_id_nam_mob)

数据库管理规范

3、1、7唯一索引命名:UI_表名_字段名(如果存在多字段唯一索引,取每字段前三个字符加下划线组合,如:在 hyid,hyname,hymobile上建立唯一索引,命名:UI_表名_hyi_hyn_hym,如果前三个截取字符相同,就从字段名称中不同的字符开始取三个字符加下划线组合,如:在 zhyid,zhyname,zhymobile上建立唯一索引,命名:UI_表_id_nam_mob)

3、1、8主键命名:PK_表名_字段名(如果存在多字段主键,取每字段前三个字符加下划线组合,如:在 hyid,hyname,hymobile上建立主键,命名:PK_表名_hyi_hyn_hym,如果前三个截取字符相同,就从字段名称中不同的字符开始取三个字符加下划线组合,如:在 zhyid,zhyname,zhymobile上建立主键,命名:PK_表_id_nam_mob)

3、1、9外键命名:FK_表名_主表名_字段名

3.1.10 Sequence命名:SEQ_表名_列名(或者根据需要另取名字)

3.2 设计原则

3、2、1表的设计

? 【强制】每个表,都必须要有主键。主键就是每行数据的唯一标识,保证主键不可随意更

新修改,在不知道就是否需要主键的时候,请加上主键,它会为您的程序以及将来查找数

据中的错误等等,提供一定的帮助;

? 【强制】所有的MySQL数据库除历史原因外,都必须采用UTF8编码

? 【建议】一个表的某列与另一表有关联关系的时候, 请在应用程序维护外键关系,如果

在数据库建立外键约束请遵循以下几点:

尽量少使用外键,在高并发下数据库会增加较大开销;

不要以数据操作不方便为理由而不建外键。加上外键以后,一些数据操作变得有些麻烦,但就是这正就是对数据一致性的保护

以缺省的方式建立外键(即用delete restrict方式),以达到保护数据一致性的目的; ? 【强制】外键一定要建立索引。

? 【建议】单表行数超过 500万行或者单表容量超过 2GB,才推荐进行分库分表 3、2、2列的设计

? 【强制】字段命名必须用英文来定义,如果太长可用缩写;

? 【强制】相应类型数据存入相应类型字段(如:数字=>NUMBER,日期=>DATE,

定长字符=>CHAR,变长字符=>VARCHAR2等)否则会自动进行不必要的类型

转换,降低性能,破坏数据完整性

? 【强制】表达就是与否概念的字段,必须使用 is_xxx的方式命名,数据类

型就是 unsigned tinyint( 1表示就是,0表示否) ? 【强制】小数类型为 decimal,禁止使用 float与 double

? 【建议】varchar就是可变长字符串,不预先分配存储空间,长度不要超过

5000,如果存储长度大于此值,定义字段类型为 text,独立出来一张表,用

数据库管理规范

主键来对应,避免影响其它字段索引效率

? 【建议】字段的宽度要在一定时间内足够用,但也不要过宽,占用过多的存

储空间;

? 【建议】除非必要,否则尽量不加冗余列。所谓冗余列,就是指能通过其她列计算出来的列,或者就是与某列表达同一含义的列,或者就是从其她表

复制过来的列等等。冗余列需要应用程序来维护一致性,相关列的值改变的时候,冗余列也需要随之修改,而这一规则未必所有人都知道,就有可能因此发生不一致的情况。如果就是应用的特殊需要,或者就是为了优化某些逻辑很复杂的查询等操作,可以加冗余列; 3、2、3 索引的设计

? 【强制】业务上具有唯一特性的字段,即使就是组合字段,也必须建成唯一索引 ? 【强制】超过三个表禁止 join。需要 join的字段,数据类型保持绝对一致;

多表关联

? 【强制】查询时,保证被关联的字段需要有索引

? 【强制】在 varchar字段上建立索引时,必须指定索引长度,没必要对全字段

建立索引,

? 【强制】页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决 ? 【强制】如果有 order by的场景,请注意利用索引的有序性。order by 最后

的字段就是组合索引的一部分,并且放在索引组合顺序的最后,避免出现 的

情况,影响查询性能。

正例:where a=? and b=? order by c; 索引:a_b_c ? 【强制】建组合索引的时候,区分度最高的在最左边 ? 【建议】性能测试阶段收集90%SQL后,统一设计建立索引 ? 【建议】根据实际文本区分度决定索引长度。

说明:索引的长度与区分度就是一对矛盾体,一般对字符串类型数据,长度为 20的索引,区分度会高达 90%以上,可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。

数据库管理规范

4、 SQL编写规范

? 【强制】禁止开发人员在SQL中添加 Hint,Hint只能由DBA审核后添加。 ? 【强制】禁止使用悲观锁定,即读锁 select … for update。

? 【强制】禁止在开发代码中使用DDL语句,比如 truncate,alter table … 等。

? 【强制】禁止使用与系统环境相关的mysql inside 函数,列如UUID(),USER(),sysdate()这些

函数,这样可能会导致主从同步不一致。

? 【强制】禁止在充当读角色的mysqld上执行写操作(写操作指update,delete,insert),因为

可能导致同步中断或者数据不一致。

? 【强制】不要使用 count(列名)或 count(常量)来替代 count(),count()就就是 SQL92定义

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

? 【强制】说明:count(*)会统计值为 NULL的行,而 count(列名)不会统计此列为 NULL值

的行

? 【强制】使用 ISNULL()来判断就是否为 NULL值。注意:NULL与任何值的直接比较都为

NULL

? 【强制】禁止使用存储过程,存储过程难以调试与扩展,更没有移植性

? 【强制】在表查询中,一律不要使用 * 作为查询的字段列表,需要哪些字段必须明确写明 ? 【强制】表连接操作中,作为连接条件的字段的数据类型严格一致。

? 【强制】如果表连接字段数据类型不一致,在SQL中用显示用类型转换,具体情况咨询

DBA。

示例

正确用法1:select col1, col2 from tbl1, tbl2 where tbl1、col3 = tbl2、col4;

其中“tbl1、col3”与“tbl2、col4”数据类型严格一致。 ? 【建议】必须正确开启事务并且显式关闭事务

? 【建议】使用域名连接数据库。 禁止线上应用使用IP地址连接数据库。

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

控制在 1000个之内。