一、核心理念

1.1、制定规范的目的:

制定规范的直接目的是约束设计行为,最终目的是确保设计的合理、统一。规范虽然是由丰富项目经验的人制定的,但维护的却不是某个人的意志,而是集体智慧的意志,公司的意志,因为遵守此规范对项目、对公司是好的、有利的,此规范才有意义。

1.2、对于数据库核心理念可以归纳为以下几点:

  1. 遵从规范应该从数据库设计之初就开始考虑,团队TL审核后请DBA预审,然后放放心心做开发,而不是等到上线了才发审批。
  2. 做好数据库的读写分离,主库负责写以及少量的实时读,从库负责数据的读(这是从架构上)。
  3. 平衡范式与数据冗余,为提高查询效率可以在模式设计的时候,根据具体的业务适当的做数据字段的冗余(这是从模式上)。
  4. 尽可能不在数据库层做计算,CPU计算务必移至业务层。
  5. 控制单表大小以及数据量,单表记录数控制在千万级,单表大小在20GB内。每一行的大小在16KB内,可以适当的对数据表做垂直切分来实现。
  6. 控制列数量,字段数控制在30以内。
  7. 拒绝3B(BIG),大SQL,大事务,大批量。
  8. 采用队列方式合并多次写请求,持续写入,避免瞬间压力。
  9. 单个实例下数据库的总数不宜超过50,一个数据库下的实体(表)总数在500内。
  10. 富文本数据不应存储到数据库,设计时应当只存储到OSS然后数据字段存储url调用。

二、表结构的设计规范

2.1、关于表:

  1. 表名称(TABLE NAME)新创建项目要全部小写,例如dsb\_import\_record,原有项目表名大小写不强制规范,但是要保持统一。
  2. 表名称(TABLE NAME)在新创建项目时,客户业务强相关的项目表要全部使用拼音首字母缩写构成,做到见名知意,并且加上项目首字母缩写前缀,例如(‘丁税宝虚拟组织协议’的表名为'dsb\_xnzz\_xy'),通用基础能力相关的项目表可以用英文,并且加上功能前缀,例如(‘用户’的表名为'app\_user'),原有项目沿用之前的表名设计规则,不做强制更改,但是要保持统一。
  3. 临时表(TMP TABLE)对于临时表需要使用TMP\_开头,这些表方便后面定期清理。
  4. 备份表(BACKUP TABLE)对于一些备份的表需要使用\_BACKUP结尾,这些表需要做定期的清理。
  5. 表的名称长度(TABLE NAME LENGTH)所有的数据表的名称长度需要控制在22个字符内。
  6. 表的名称不能使用MYSQL的保留字,比如TYPE,NAME,CHAR等。
  7. 所有的表在创建的时候必须指定COMMENT备注,采用中文描述该表是做什么的。

2.2、关于字段:

  1. 自增ID,建议创建一个无符号的自增ID作为主键,统一使用BIGINT。
  2. 对于业务类主键,需要在创建的时候,指明NOT NULL非空约束,并创建唯一性索引UNIQUE INDEX。
  3. 表字段的名称必须全部是大写拼音首字母缩写构成,例如XNZZ_ID代表 '虚拟组织ID',只有个别通用型字段允许使用英文单词例如'ID','IS\_DELETED'。通用基础能力相关表字段允许使用大写英文单词,但是要保证同一项目内的字段统一。不允许同一项目出现中文拼音字段和英文单词字段混合使用的情况。
  4. 字段名称的长度必须控制在20个字符之内,尽可能的进行简化缩写不允许出现“dfnlnflsndlfnadkfndl”这类超长的字符串构成字段名称。
  5. 字段的名称不能使用MYSQL的保留字,比如(NAME,TYPE,STATUS等)。
  6. 字段的名称要做到见名知意,可以清楚的表达这个字段是做什么的。
  7. 每个字段后面必须写明COMMENT备注信息,用中文描述这个字段是做什么的,表示什么含义,备注调用其它表字段以及字段解释用() 例如:用户ID(APP\_USER.ID),加密方式使用#标出 例如:#CryptSimple#。
  8. 对于类似TINYINT拥有可选值的字段(字段不限于TINYINT),必须申明NOT NULL约束,并赋予一个默认值,格式举例\\(ITEM\_NAME TINYINT UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘项目名称:10=XXX,20=XXX’)#对于只有是否类枚举0=否1=是,其它类型枚举用10位整数表示大类,之后细分小类,例如10=手机,11=安卓手机,20=电脑,21=苹果电脑#。\\
  9. 字段类型的选择要遵循最小原则,即能使用VARCHAR(20)可以保证业务满足的情况下,不使用VARCHAR(30) ,除了特殊用法外固定长度varchar长度取整:10,20,30,50,100,200,300等。
  10. 在业务表中不允许使用大量的例如VARCHAR(200),VARCHAR(500),VARCHAR(1000)等这类大字段。
  11. 禁止在业务主表中使用TEXT、BLOB这类数据类型,需要存储的话,需要设计为扩展表。
  12. 关于手机号的存储,因为在数据存储的时候是加密存储的,所以统一使用VARCHAR(30)
  13. 对于状态类字段统一使用TINYINT UNSIGNED,并标明每个状态的含义。
  14. 对于存储一些金额类的数据,必须使用DECIMAL类型,禁止使用FLOAT以及DOUBLE这类数据类型,因为这样在计算求和的时候会造成精度的丢失。
  15. 对于记录的有效性,统一采用ENABLED字段,有两个值(0,1),默认为1,表示记录有效。
  16. 对于记录的可见性,统一使用VISABLE字段,有两个值(0,1),默认是1,表示记录是可见的。
  17. 对于记录的创建时间:统一使用CREATION\_DATE,数据类型统一使用TIMESTAMP。
  18. 对于一些交易类的数据表,可能需要记录该记录的创建者跟修改者,以及修改的时间,这类表中,统一使用CREATOR来表示该记录是由谁创建的,MODIFICATION\_DATE来表示该记录的修改时间,MODIFIER来表示该记录最后一次的修改者是谁。
  19. 日期类字段起名统一在功能后加date,非特殊用法用全量日期用datetime不用timestamp,对于需要进行按照日期进行分组统计的表,为了避免进行字段上的函数比较处理,可以适当的冗余字段,类型为DATE。
  20. 一个表的字段数要控制在30个以内。
  21. 固定长度的字段要使用CHAR类型。例如:CHAR(20)
  22. 同一个字段在多个表中类型必须保证一致,防止出现同名易义以及易名同意。
  23. 不建议使用VARCHAR类型的字段做主键,如果业务实在是有需要可以使用CHAR类型的固定长度。
  24. 字段长度设计需要兼容第三方的系统,例如:金三系统中企业名称长度是100,那么系统设计中名称长度也必须是100,人名75长度加密,电话30长度加密,税务机关代码11长度,纳税人识别号30长度加密,社会信用代码20长度加密,url长度255长度加密。
  25. 字段长度需要符合计算设计,例如:一个企业有很多层级关系,假设最大是5级,每一级长度限定为10,在另一个表中设计一个字段存储每一级的名称,那么这个字段的长度就是5\*10=50
  26. DRDS建表自增ID统一使用GROUP,对于特殊需求(需要自增ID连续的且不分表的需要经DBA确认后才可以创建)
  27. 在定义表字段的时候需要将固定长度的字段放在前面。
  28. 位运算需要使用INT类型,不允许使用字符串类型。
  29. 对于全路径的设计需要使用如下的形式(id1/id2/id3)。
  30. 多表关联查询,关联的表的个数不能超过两个,且一个SQL语句经过SQL格式化之后不允许超过50行。

2.3、关于索引:

  1. 在创建表的时候,对于主键类(PRIMARY KEY)的需要使用PK\_列(列名)。
  2. 在创建表的时候,对于唯一类的索引(UNIQUE INDEX)需要使用UK\_列(列名)。
  3. 在创建表的时候,对于普通类索引需要使用IDX\_列(列)。
  4. 在创建表的时候,对于普通类索引当是多个字段构成的组合索引的时候,基数较大的字段需要在前面。
  5. 索引的名称需要控制在20个字符内。
  6. 一个表的索引需要控制在5个内。
  7. 一个索引包含的数据列不能超过5个。
  8. 在区分度较小的字段上不允许创建索引(例如性别,状态等字段)。
  9. 索引列要避免NULL值的使用。
  10. 联合索引必须将区分度也就是基数较大的放在左边第一列。
  11. 避免建立冗余索引。比如:联合索引IDX\_A\_B\_C(A,B,C) 相当于 (A) 、(A,B) 、(A,B,C),那么索引 (A) 、(A,B) 就是多余的。
  12. 索引的名字都要以IDX\_开头,索引名字的长度在20个字符内

2.4、通用规则:

  1. 禁止在数据表上创建外键约束。
  2. 所有的数据表统一使用UTF8字符集。
  3. 禁止使用存储过程、触发器、EVENT等。
  4. 对于一些小的数据表,需要在每个分库中都存在的,需要创建使用广播表。
  5. 日志类的数据不要存在MYSQL数据库上。
  6. 禁止在MYSQL中存储图片文件等。

三、SQL操作类规范

3.1、SQL 语句的所有表名,列名必须全部大写,SQL的保留字全部采用大写。

举例: SELECT WZID,WZNR,XGSJ,CJSJ FROM BSZN\_WZLB WHERE CJSJ=XXX

3.2、禁止SELECT \*

在查询语句中,不允许存在 SELECT \* FROM TABLE\_NAME这类\*的存在,必须要写明具体查询的列信息。

3.3、关于连接符

在连接符 OR IN AND >= <= = 等这类操作的前后必须加上空格。

3.4、关于OR

对于OR 这类操作,必须使用()进行逻辑区分,更好的理解逻辑含义。举例: SELECT ID,USERNAME,NICK\_NAME FROM APP\_USER WHERE ID = xxx AND MAP\_ID = xxx OR PIN = xxx 必须要写成: SELECT ID,USERNAME,NICK\_NAME FROM APP\_USER WHERE (ID = xxx AND MAP\_ID = xxx) OR PIN = xxx

3.5、SQL书写注意缩进

SQL语句的书写好尽可能的注意缩进,匹配关联的字段要是一行,条件过滤是一行,当多表关联的时候,采用表名.列名进行区分。下面举个例子: SELECT A.COLUMNA AS COLUMNA, A.COLUMNC AS COLUMNC, B.COLUMNB AS COLUMNB, B.COLUMND AS COLUMND        FROM A INNER JOIN B ON A.ID = B.ID AND A.PID = B.PID WHERE A.COLUMN = XXX AND B.COLUMN = XXX;

3.6、尽可能使用常量过滤数据

WHERE条件中的数据过滤尽可能的使用常量进行比较。

3.7、小表驱动大表的原则

在多表关联的时候,采用小表驱动大表的方式,即FROM后面的第一个表是返回结果集较小的表。下面这个是一个简单的例子: SELECT COLUMN FROM A INNER JOIN B ON A.ID=B.ID WHERE A.COLUMN=XXX AND B.COLUMN=XXX 其中A表是小表B表是大表

3.8、避免大量的分组排序

大量的分组、排序会造成系统的性能下降,尽可能的减少排序这块的操作。如果必须在数据库上做排序,那么排序的字段尽可能使用有索引的列,或者主键。

3.9、UNION ALL与UNION

当结果集不需要唯一的时候,可以使用UNION ALL代替UION。

3.10、直接使用SELECT COUNT(主键)

不允许直接使用SELECT COUNT(\*) FROM TABLE\_NAME;这类语句直接对表进行统计。

3.11、禁止INSERT 不带列名的插入

不允许使用INSERT INTO TABLE\_NAME VALUES()这类语句,在插入数据的时候,必须写明具体的列跟具体的数值。

3.12、禁止类型转换

禁止使用类型转换,比如在WHERE条件中某一列是INT类型,但是比较的时候使用引号进行了比较(SELECT COLUMN FROM TABLE\_NAME WHERE ID=’XXX’)。

3.13、禁止字段上用函数

禁止在数据过滤的时候WHERE条件的字段上使用函数,例如(SELECT COLUMN FROM TABLE\_NAME WHERE DATE(CREATE\_DATE)=’XXX’)。

3.14、禁止LIKE全模糊查询

禁止在数据查询的时候使用LIKE的全模糊匹配,例如(SELECT COLUMN FROM TABLE\_NAME WHERE ID LIKE ’%XXX%’)。

3.15、禁止IN查询(IN的结果集很大)

严格禁止在查询的时候使用IN结果集很大的查询,比如: SELECT ID,USERNAME,NICK\_NAME FROM APP\_USER WHERE ID IN ( SELECT ID FROM APP\_USER\_ACCOUNT WHERE PIN = 'xxx') 这个查询中IN的结果集有几万。当IN内部的结果集有两三个时,可以适当的选用。

3.16、查询匹配与索引要一致

数据查询的时候,查询列排序列以及索引的次序列要尽可能的保持一致。

3.17、采用共享SQL方式

对于同一种查询要统一SQL避免同样的SQL有多种不同的写法。

3.18、禁止EXISTS子句

在SQL查询中,不允许使用EXISTS子句。例如: SELECT COLUMN FROM USER\_COMPANY AS C WHERE EXISTS ( SELECT ORDER\_ID FROM ORDER\_TABLE AS A WHERE A.ID=C.ID)

3.19、禁止使用游标这类操作。

3.20、关联字段要一致

在对表关联查询的时候,匹配的字段类型要一致,避免同一个字段在多个表中的数据类型不一致,导致在关联查询的时候,效率低的问题。

3.21、临时表的使用

当两个表的数据量都很大,但是最终的结果很小的时候,可以使用中间表的方式进行关联匹配,采用小表驱动大表,下面是一个简单的例子。 SELECT A.COLUMNA AS COLUMNA, A.COLUMNC AS COLUMNC, B.COLUMNB AS COLUMNB, B.COLUMND AS COLUMND        FROM   (SELECT COLUMN FROM C WHERE C.COLUMN = XXX ) AS A INNER JOIN B ON A.ID = B.ID AND A.PID = B.PID WHERE A.COLUMN = XXX AND B.COLUMN = XXX

3.22、做好LIMIT分页处理

所有的数据查询,返回的结果集不能超过100,必须分页处理LIMIT M,N。

3.23、分组统计的时候要根据需要是否使用COUNT(\*)

分组统计COUNT(\*),会包含NULL值的统计,COUNT(COLUMN)不统计NULL值。

3.24、查询尽量利用索引

  1. 使用索引需注意WHERE条件以及排序、分组,比如有联合索引IDX\_A\_B\_C
  2. WHERE A=1 AND B=2 AND C=3可以完全利用索引
  3. WHERE A=1 AND C=3 AND B=2也可以利用索引,但是需要一层内存转换消耗
  4. WHERE A=1 AND B>2 AND C=3 仅可以利用A、B列索引
  5. WHERE A=1 AND B LIKE ‘HELLO%’ ORDER BY 3 仅可以利用A、B列索引
  6. WHERE A=1 AND B=2 GROUP BY C 可以利用A、B、C列索引
  7. 可以查看执行计划确认索引使用情况(EXPLAIN SQL 的TYPE)

四、业务类规范

4.1、业务表前缀指定

  1. 丁税宝业务表统一使用前缀DSB\_
  2. 税小蜜业务表统一使用前缀BOT\_
  3. 新芽业务表统一使用前缀EDU\_
  4. 支付宝业务表统一使用前缀ZFB\_
  5. 其它表默认为公共组

4.2、业务表必须包含的字段

  1. 必须包含CREATOR或者CREATOR\_ID字段,用于记录行创建人,不用于业务记录。
  2. 必须包含CREATOR\_DATE字段,用于记录行创建时间,不用于业务记录。
  3. 必须包含MODIFIER或者MODIFIER\_ID字段,用于记录行修改人(没有修改业务的表不需要加,如日志表)。
  4. 必须包含MODIFICATION\_DATE字段,用于记录行修改时间(没有修改业务的表不需要加,如日志表)。

4.3、业务字段命名规范

  1. 手机号码统一英文使用MOBILE、拼音统一使用SJHM。
  2. 启用标记统一英文使用ENABLED、拼音统一使用QYBJ。
  3. 金三已有标准字段统一按照金三命名。

4.4、加密类规范

  1. 反射BEAN和MAPPER文件时必须使用公司的反射工具
  2. 公司的反射工具通过字段注释来区分采用何种方式加密并自动生成加解密TYPEHANDLER
  3. \#CRYPTBASE36#代表加密结果集在26个字母+10个数字范围内
  4. \#CRYPTBASE52#代表加密结果集在52个字母+10个数字范围内
  5. \#CRYPTSIMPLE#加密结果在字符串范围内
  6. 在表中凡是存储如下字段的都需要加密存储:例如纳税人(社会信用代码、纳税人识别号、企业名称、人员姓名、手机号码、地址、照片url、邮箱、银行卡号、第三方系统都账号(如短信平台账号、钉钉coripId、corpSecret等))具体的加密方法可咨询公共技术部

五、程序使用规范

5.1、禁止使用MYBATIS的部分用法

  1. 禁止使用ASSOCIATION关键字
  2. 禁止使用COLLECTION作为映射中关键字
  3. 禁止使用SELECT作为结果映射中关键字

六、其他规范

6.1、关于数据库审批时间的规定

  1. 生产库的审批发出时间必须在每日17:00点之前到达DBA组。
  2. SQL审批DEMO库的发出时间必须在每日的15:00之前到达DBA组。
  3. 其他时间的操作DBA拒绝执行。

6.2、数据库审批流程附件必须以.SQL结尾

  1. SQL必须以附件形式出现
  2. 附件必须以.SQL结尾
  3. 文件中的SQL注释不能使用“--”,而应该使用“/\* 注释 \*/”
  4. 在SQL审批的时候,创建新的数据表以及该表的初始化数据要使用一个文件,关于数据的修改需要一个单独的文件审批,对于原始数据表的表结构变更需要使用一个单独的文件。
  5. DBA不判断SQL的逻辑语义是否正确,只做语法类检查。

6.3、表结构修改必须说明目的

  1. 涉及到结构修改应说明修改目的、设计思维。
  2. 另需对比说明原来为何如此设计、现在这样改带来的好处。
  3. 表结构的修改只可以改长不可以改短,例如VARCHAR(30)到VARCHAR(50),不可以VARCHAR(50)到VARCHAR(30)。

6.4、审批流程仅指执行生产库

  1. 开发库由开发自行执行,DBA不参与这块的操作。
  2. 测试库在事业部负责人同意情况下可自行执行。
  3. 生产库以及预发布DEMO库的执行需要得到DBA的确认并且由DBA来执行

6.5、数据库权限规范

  1. 数据库的权限分为四类:
  2. 一类是创建DRDS逻辑DB时系统账号跟系统的只读账户,这两个账户由DBA组跟运维组管理,不对其他人开放。
  3. 一类是可以访问RDS的账号,这个账号完全由DBA组管理,并且密码一个月变化一次。
  4. 一类是只读账户,这个账号是面向事业部开发人员的,每个人单独一个账户,授权绑定IP的方式,不允许相互之间使用,这个账号只可以访问DRDS,不能访问RDS,并且只有SELECT权限,并且密码会每个月的自然日第一天进行变更。
  5. 一类是可以执行CRUD权限,这个账号是交给事业部开发经理,特殊情况处理问题,只能进行查询、更新、删除、增加权限,其他的操作权限没有。密码也会一个月变化一次。

6.6、数据库环境的一致性

  1. 必须要保证数据库环境的一致性,以及数据库表结构的一致性。即数据库预发布环境与生产环境的数据库架构要一致,数据库表结构预发布环境的表结构要始终比生产环境的表结构新。
  2. 所有的表结构变动首先在预发布环境执行,确保无误后再在生产上执行。

6.7、审批的SQL要注意以下几点

  1. 对同一个表的操作,增加字段,删除字段,修改类型,增加索引,删除索引,必须写成一个SQL,单条ALTER语句,不允许分开写,避免出现同一个表的多次交互。
  2. 审批的SQL中不允许出现SELECT @PARENTID2:= LAST\_INSERT\_ID();

6.8、RDS 参数调整

RDS 需要调整的参数及其介绍:

  1. # BACK\_LOG 默认是 3000,可以修改为 4000,MYSQL  每处理一个连接请求时都会创建一个新线程与之对应。在主线程创建新线程期间,如果前端应用有大量的短连接请求到达数据库,MYSQL 会限制这些新的连接进入请求队列,参数 BACK\_LOG 就是控制这个的。如果等待的连接数量超过 BACK\_LOG 的值,则将会出现如下的信息:SQLSTATE\[HY000] \[2002] CONNECTION TIMED OUT;
  2. \# BINLOG\_CACHE\_SIZE 默认是128KB,需要调整为2MB。可以根据参数状态 BINLOG\_CACHE\_DISK\_USE BINLOG\_CACHE\_USE 这两个的值来判断是否需要调整这个参数。
  3. \# BINLOG\_STMT\_CACHE\_SIZE 默认是 32768,需要调整为 1MB。可以根据参数状态 BINLOG\_STMT\_CACHE\_USE BINLOG\_STMT\_CACHE\_DISK\_USE 这两个的值来判断是否需要调整这个参数。
  4. \# CHARACTER\_SET\_SERVER 必须设置为是 UTF8。
  5. \# CONNECT\_TIMEOUT 默认为10,修改为 1000,用于解决如下错误 LOST CONNECTION TO MYSQL SERVER AT 'XXX'。
  6. \# DEFAULT\_STORAGE\_ENGINE 必须为 INNODB。
  7. \# DEFAULT\_TIME\_ZONE 必须为 SYSTEM。
  8. \# GROUP\_CONCAT\_MAX\_LEN 默认是 1024,主要解决分组 GROUP BY的时候GROUP\_CONCAT超过限制的问题。
  9. \# INNODB\_ADAPTIVE\_HASH\_INDEX 需要开启。设置为 ON。
  10. \# INNODB\_AUTOINC\_LOCK\_MODE 默认是 1,需要调整为 2,主要是解决并发导入数据时出现的自增锁问题。同时在 INSERT … SELECT 的场景下性能会有很大提升。
  11. \# INNODB\_LOCK\_WAIT\_TIMEOUT 默认是50S,当出现 ERROR 1025 锁超时等待的时候,可以适当的调整这个参数的设置。
  12. \# INNODB\_MAX\_DIRTY\_PAGES\_PCT 默认是75,可以适当的调整为90,表是脏数据页的百分比。INNODB 尝试从缓冲池中刷新数据。
  13. \# INNODB\_PRINT\_ALL\_DEADLOCKS 默认是 OFF,表示是否打印所有的死锁信息,默认是只打印最后一次的死锁信息。
  14. \# INNODB\_PURGE\_THREADS 默认是1,表示INNODB后台处理 PURGE 线程的数量,可以调整为4。
  15. \# INNODB\_READ\_IO\_THREADS INNODB\_WRIYE\_IO\_THREADS 默认是4,可以根据机器的配置做优化,可以都改为8。
  16. \# INNODB\_STRICT\_MODE 默认是关闭的,需要开启,以错误的形式告知而不是警告的方式。
  17. \# INTERACTIVE\_TIMEOUT 默认是 3600,服务器在关闭交互式连接之前等待活动的秒数。
  18. \# JOIN\_BUFFER\_SIZE 默认是 352KB,在进行关联查询,索引扫描等的时候缓冲器的大小,可以设置为2MB。
  19. \# LOG\_QUERIES\_NOT\_USING\_INDEXES 默认是关闭的,需要开启。表示未使用索引的扫描是否记录在慢日志中。
  20. \# LONG\_QUERY\_TIME 默认是1,表示多长时间的SQL会被记录在慢日志中。
  21. \# LOOSE\_MAX\_STATEMENT\_TIME 用于控制查询在 MYSQL 的最长执行时间。如果超过该参数设置的时间,查询将会自动失败,默认是不限制。需要设置为5S。可以看到错误信息ERROR 3006 (HY000): QUERY EXECUTION WAS INTERRUPTED, MAX\_STATEMENT\_TIME EXCEEDED。
  22. \# LOOSE\_RDS\_MAX\_TMP\_DISK\_SPACE 用于控制 MYSQL 能够使用的临时文件的大小。默认是 10737418240,主要是解决 THE TABLE ‘/HOME/MYSQL/DATAXXX/TMP/#SQL\_2DB3\_1’ IS FULL 这类错误。
  23. \# LOOSE\_RDS\_THREADS\_RUNNING\_HIGH\_WATERMARK 用于控制 MYSQL 并发的查询数目,比如将 RDS\_THREADS\_RUNNING\_HIGH\_WATERMARK 的值设置为 100,则允许 MYSQL 同时进行的并发查询为 100 个,超过限制数量的查询将会被拒绝掉。该参数与 RDS\_THREADS\_RUNNING\_CTL\_MODE 配合使用(默认值为SELECT)。
  24. \# MAX\_ALLOWED\_PACKET 默认最大的数据包,设置为 500MB 即可。
  25. \# MAX\_CONNECT\_ERRORS 最大的错误连接数,可以调整为1000。
  26. \# MAX\_LENGTH\_FOR\_SORT\_DATA 默认是1024,可以调整为2048。
  27. \# NET\_READ\_TIMEOUT 默认是1000,当服务器从客户端读取时,NET\_READ\_TIMEOUT是控制何时中止的超时值
  28. \# NET\_WRITE\_TIMEOUT 默认是1000,等待将一个 BLOCK 发送给客户端的超时时间。
  29. \# SORT\_BUFFER\_SIZE 这个表示为排序操作设置的缓冲区的大小,这个参数不是对特定引擎的,而是通用的参数。
  30. \# TMP\_TABLE\_SIZE 该参数用于决定内部内存临时表的最大值,每个线程都要分配,实际起限制作用的是 TMP\_TABLE\_SIZE 和 MAX\_HEAP\_TABLE\_SIZE 的最小值。如果内存临时表超出了限制,MYSQL 就会自动地把它转化为基于磁盘的 MYISAM 表。优化查询语句的时候,要避免使用临时表,如果实在避免不了的话,要保证这些临时表是存在内存中的。
  31. \# EXPLICIT\_DEFAULTS\_FOR\_TIMESTAMP 这个参数表示在使用 TIMESTAMP 类型的字段是否允许非法值的问题。

七、线上数据库操作规范

7.1、数据修改必须做好备份以及信息确认

涉及到线上业务数据的增加、修改、删除数据,在得到钉钉“数据库变更申请”流程批准之后才可以执行,并且在执行之前做好备份,从而方便回滚。 变更必须走审批,口头通知视为无效。不可以进行后续补单操作。

7.2、线上业务数据变更时间必须在业务低峰期进行操作

在对大表做表结构变更时,如修改字段属性会造成锁表,并会造成从库延迟,从而影响线上业务。

7.3、禁止一个实例多个业务库

禁止一个MYSQL实例存放多个业务数据库,会造成业务耦合性过高,一旦出现问题会殃及池鱼,增加了定位故障问题的难度。通常采用多实例解决,一个实例一个业务库,互不干扰。

7.4、禁止在业务库上做统计等操作

禁止在主库上执行后台管理和统计类的功能查询,这种复杂类的SQL会造成CPU的升高,进而会影响业务。

7.5、数据清洗需要DBA跟开发一起操作

批量清洗数据,需要开发和DBA共同进行审查,应避开业务高峰期时段执行,并在执行过程中观察服务状态。

7.6、禁止在线上做数据库压力测试

数据库一旦上限,就不允许再执行压力测试

7.7、大批量的数据导入不允许在业务高峰期执行

大批量的数据导入不允许在业务高峰期执行,并且必须提前通知DBA什么时间会有大量的数据导入等操作。方便DBA及时的观察数据库的性能以及压力等。