「自学哈网」MySQL数据库的行为规范有哪些？-自学哈网

MySQL数据库的行为规范有哪些？

一、基本规范

1、禁止在数据库中存储明文密码。

2、使用InnoDB存储引擎。支持事务，行级锁，更好的恢复性，高并发下性能更好。

3、表字符集默认使用utf8，必要时候使用utf8mb4
解读：
（1）通用，无乱码风险，汉字3字节，英文1字节
（2）utf8mb4是utf8的超集，有存储4字节例如表情符号时，使用它

4、所有表和字段都需要添加中文注释。方便他人、方便自己。

5、不在数据库中存储图片、文件等大数据。
解读：图片、文件更适合于GFS分布式文件系统，数据库里存放超链接即可。”

6、避免使用存储过程、视图、触发器、事件。

MySQL是OLTP应用，最擅长简单的增、删、改、查操作，但对逻辑计算分析类的应用，并不适合，所以这部分的需求通过程序上实现。

7、避免使用外键，外键用来保护参照完整性，可在业务端实现。

“解读：外键会导致父表和子表之间耦合，十分影响SQL性能，出现过多的锁等待，甚至会造成死锁。”

8、对事务一致性要求不高的业务，如日志表等，优先选择存入MongoDB。

MongoDB其自身支持的sharding分片功能，增强了横向扩展的能力，开发不用过多调整业务代码。

9、命名规范

禁止使用中文命名。命名少于30个字符的系统限制，变量名的长度限制为29(不包括标识字符@)。命名都采用英文字符，每个单词的字母尽量要大写。

对象命名，如存储过程以SP_为前缀；触发器以TR_为前缀；函数以FN_为前缀；主键以PK_为前缀；索引以IX_为前缀。

二、行为规范

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

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

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

4、促销活动等应提前与DBA当面沟通，进行流量评估，比如提前一周增加机器内存或扩展架构，防止DB出现性能瓶颈。

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

三、人员操作规范

1、涉及业务上的修改/删除数据，在得到业务方、CTO的邮件批准后方可执行，执行前提前做好备份，必要时可逆。

2、所有上线需求必须走工单系统，口头通知视为无效。

3、在对大表做DDL操作时，业务低峰时操作。MySQL 5.6版本之前使用pt-osc工具，5.6版本开始支持online DDL操作。

4、所有线上业务库均必须搭建MHA高可用架构，避免单点问题。

5、给业务方开权限时，密码要用MD5加密，至少16位。权限如没有特殊要求，均为select查询权限，并做库表级限制。

6、删除默认空密码账号。

7、汇总库开启Audit审计日志功能，出现问题时方可追溯。

四、库表设计规范

很多中小公司，都是开发自己进行库表的涉及，没有专职DBA或者没有与运维确认，我想作为运维在项目评审初期，应该对此问题，进行规范。

1、表必须有主键，例如自增主键。

这样可以保证数据行是按照顺序写入，对于SAS传统机械式硬盘写入性能更好，根据主键做关联查询的性能也会更好，并且还方便了数据仓库抽取数据。从性能的角度来说，使用UUID作为主键是个最不好的方法，它会使插入变得随机。

2、慎用分区表。

分区表的好处是对于开发来说，不用修改代码，通过后端DB的设置，比如对于时间字段做拆分，就可以轻松实现表的拆分。但这里面涉及一个问题，查询的字段必须是分区键，否则会遍历所有的分区表。所以应采用切表的形式做拆分，如程序上需要对历史数据做查询，可通过union all的方式关联查询。另外随着时间的推移，历史数据表不再需要，只需在从库上dump出来，即便捷地迁移至备份机上。