江苏龙网

  1. 主页 > 生活百科 > >

用惨痛教训换来的156条MySQL设计规约

MySQL设计

怎么才能很好地避免低级故障？以下规范在大型互联网公司经过了充分验证，尤其适用于并发量大、数据量大的业务场景 。
在设计数据库技术方案时，我们是有自己的设计理念或者原则，还是更多依据直觉去设计？是否曾经懊悔线上发生过的一次低级故障？是否思考过怎样才能避免？设计规范的价值在于提供了一份工作检查清单，我们不断从错误中积累有效经验，指导未来的工作 。
以下规范在大型互联网公司经过了充分的验证 ， 尤其适用于并发量大、数据量大的业务场景 。安全无小事，很多公司都曾经因为数据泄露导致用户损失惨痛 ， 所以将安全规范放到了第一位 。?
一、安全规范
1.【强制】禁止在数据库中存储明文密码 ， 需把密码加密后存储 。
说明：对于加密操作建议由公司的中间件团队基于如MyBatis的扩展 ， 提供统一的加密算法及密钥管理 ， 避免每个业务线单独开发一套，同时也与具体的业务进行了解耦 。
2.【强制】禁止在数据库中明文存储用户敏感信息，如手机号等 。
说明：对于手机号建议公司搭建统一的手机号查询服务，避免在每个业务线单独存储 。
3.【强制】禁止开发直接给业务同学导出或者查询涉及到用户敏感信息的数据，如需要需上级领导审批 。
4.【强制】涉及到导出数据功能的操作，如包含敏感字段都需加密或脱敏 。
5.【强制】跟数据库交互涉及的敏感数据操作都需有审计日志，必要时要做告警 。
6.【强制】对连接数据库的IP需设置白名单功能，杜绝非法IP接入 。
7.【强制】对重要sql（如订单信息的查询）的访问频率或次数要做历史趋势监控，及时发现异常行为 。
8.【推荐】线上连接数据库的用户名、密码建议定期进行更换 。
二、基础规范
1.【推荐】尽量不在数据库做运算，复杂运算需移到业务应用里完成 。
2.【推荐】拒绝大sql语句、拒绝大事务、拒绝大批量，可转化到业务端完成 。
说明：大批量操作可能会造成严重的主从延迟，binlog日志为row格式会产生大量的日志 。
3.【推荐】避免使用存储过程、触发器、函数等 ， 容易造成业务逻辑与DB耦合 。
说明：数据库擅长存储与索引、要解放数据库CPU，将计算转移到服务层、也具备更好的扩展性 。
4.【强制】数据表、数据字段必须加入中文注释 。
说明：后续维护的同学看到后才清楚表是干什么用的 。
5.【强制】不在数据库中存储图片、文件等大数据 。
说明：大文件和图片需要储在文件系统 。
6.【推荐】对于程序连接数据库账号，遵循权限最小原则 。
7.【推荐】数据库设计时，需要问下自己是否对以后的扩展性进行了考虑 。
8.【推荐】利用 pt-query-digest 定期分析slow query log并进行优化 。
9.【推荐】使用内网域名而不是ip连接数据库 。
10.【推荐】如果数据量或数据增长在前期规划时就较大，那么在设计评审时就应加入分表策略 。
11.【推荐】要求所有研发SQL关键字全部是小写，每个词只允许有一个空格?
三、命名规范
1.【强制】库名、表名、字段名要小写，下划线风格 ， 不超过32个字符，必须见名知意，建议使用名词而不是动词，词义与业务、产品线等相关联 ， 禁止拼音英文混用 。
2.【强制】普通索引命名格式：idx_表名_索引字段名（如果以首个字段名为索引有多个，可以加上第二个字段名，太长可以考虑缩写），唯一索引命名格式：uk_表名_索引字段名（索引名必须全部小写，长度太长可以利用缩写），主键索引命名：pk_ 字段名 。
3.【强制】库名、表名、字段名禁止使用MySQL保留字 。
4.【强制】临时库表名必须以tmp为前缀，并以日期为后缀 。
5.【强制】备份库表必须以bak为前缀，并以日期为后缀 。
6.【推荐】用HASH进行散表，表名后缀使用16进制数，下标从0开始 。
7.【推荐】按日期时间分表需符合YYYY[MM][DD][HH]格式 。
8.【推荐】散表如果使用md5（或者类似的hash算法）进行散表 ， 表名后缀使用16进制，比如user_ff 。
9.【推荐】使用CRC32求余（或者类似的算术算法）进行散表 ， 表名后缀使用数字，数字必须从0开始并等宽，比如散100张表，后缀从00-99 。
10.【推荐】使用时间散表，表名后缀必须使用特定格式，比如按日散表user_20110209、按月散表user_201102 。


推荐阅读


上一篇：解决 Java 打印日志吞异常堆栈的问题

下一篇：业务系统常用限流算法浅析