- 2022/04/19 第一版定稿
- 2022/05/07 删除 “普通索引创建使用 KEY” 的描述 说明： ◦ 本规范根据金山协作后台业务情况制定； ◦ 如果公司规范 MySQL使用规范（面向RD）中有而本规范中没有的，应参考公司规范，其他情况下，都以本规范为准； ◦ 本规范不适用与 Hadoop 等大数据平台创建的数据统计表； ◦ 规范主要分为三种内容，可读性提升、统一约束与业务相关规范，在业务规范我们遵循避免复杂操作、避免数据库运算的原则，这是因为复杂操作对技术性要求相对较高、容易造成失控的查询过程、失控的结果，导致数据库的CPU、内存或者磁盘压力突增给业务带来不可控的影响，还有一个原因是业务后台使用的数据库并不统一（国产数据库的支持情况），不是所有的复杂操作在各个数据库中通用，数据库运算同理； ◦ 附：之前的规范讨论记录：MySQL表设计以及SQL规范（讨论） ； ◦ 附：SQL索引分析一例；
• 表名使用小写字母单词，多个单词以下划线分隔，不推荐超过32个字符； • 表名和字段名尽量避免使用拼音、禁止使用拼音简写，字段命名需要表示其实际含义的英文单词或简写； • 同一业务或者模块的表尽可能使用相同的前缀，表名称尽可能表达含义； • 建议对表的用途进行注释说明，以便于统一认识，字段尽量添加注释； • 主键不要带有业务含义，建议每张表都使用 id 字段作为自增主键，字段类型推荐使用 bigint unsigned； • 除 id 字段外，建议各表之间相同意义的字段应同名，并且一定使用相同的字段类型； • 添加列不允许使用 AFTER，表名、列明、索引名称都要使用 `` 包裹； • 表与字段使用 utf8mb4 编码与 utf8mb4_general_ci 字符集； • 禁止使用外键，如果有外键约束，应该用程序控制；
• 创建索引时尽量添加注释； • 修改唯一索引时，例如新增一列作为新的唯一索引，需要先 add 新索引，后 drop 旧索引； • 唯一索引创建使用 UNIQUE KEY ，前缀使用 idx_uk_xx；前缀使用 idx_xxxx； • 尽量创建有效、适用性高的索引，减少不必要的索引； • 禁止建立重复索引，禁止在已有联合索引的情况下建立有被包含关系的索引； • 禁止在更新十分频繁、区分度不高的属性上建立索引，在索引区分度高（80%）的字段上建立索引效率更高； • 使用多个索引创建联合索引时，务必遵守最左匹配原则；
• 禁止使用 select * 进行查询，建议按需求选择合适的字段列，杜绝直接 select * 读取全部字段，减少网络带宽消耗，有效利用覆盖索引； • 禁止使用 join、union、union all 操作，除非可预期扫描行数不大或者超小表的情况（笛卡尔积不超过1000）； • 尽量避免使用 case when 等复杂查询结构； • 尽量避免使用 having，建议使用 where 进行过滤，如果 where 无法满足需求，应该考虑拆分 SQL 在程序中进行计算； • 尽量避免使用 on duplicate key update 、insert ignore into进行插入更新操作，建议使用事务与 select 、 insert 两条语句组合的方式替代; • 使用 insert 插入数据时，不得省略 columns； • 强制执行 ONLY_FULL_GROUP_BY 规范； • 禁止使用 MySQL 函数、存储过程、触发器；
• 尽量使用单语句、单表的简单查询； • 尽量避免使用嵌套子查询； • 除专用内部统计表外，应尽量避免存储宽表； • 不得将域名、带域名的URL存储到数据库，应该在业务逻辑中拼接； • 不得物理删除表数据，重要业务数据应该记录字段软删除时间； • 业务语句中使用 like 查找字符串不得将 % 放在首位（这会导致无法命中索引），或者使用时结合其他有效的约束条件; • 单表数据不得超过4000万行，如果有预期超过，应该提前做好分表设计； • 禁止在业务高峰时期执行可预期扫描量大的业务统计操作，如有此类需求，可以提前规划好时间并和团队、DBA沟通； • 必要时候为了提高效率，对于非关键或有歧义不会造成业务影响的数据，可以考虑进行冗余存储；
• 所有 DAO 方法都要有对应单元测试； • 字符串必须使用 mysql.Escape 方法进行转义； • 业务对外提供接口时，需要使用 id 作为条件的，应该考虑是否存在越权问题和遍历问题。