MySQL军规

一,基础规范

• 表存储引擎必须使用InnoDB
• 表字符集默认使用utf8,必要时使用utf8mb4

解读:

(1)通用,无乱码风险,汉字3个字节,英文1个字节

(2)utf8mb4是uft8的超集,有存储4字节例如表情符号时,使用它

• 禁止使用存储过程,视图,触发器,Event

解读:

(1)对数据库性能影响较大,互联网业务,能让站点层和服务层干的事情,不要交到数据库层.

(2)调试,排错,迁移都比较困难,扩展性较差.

• 禁止在数据库中存储大文件,例如照片,能够将大文件存储在对象存储系统,数据库中存储路径
• 禁止在线上环境作数据库压力测试
• 测试,开发,线上数据库环境必须隔离

二 命名规范

• 库名,表名,列名必须小写,采用下划线分割
• 库名表名列名必须见名知义,长度不能超过32个字符
• 库备份以bak为前缀,以时间为后缀
• 从库必须以-s为后缀
• 备库必须以-ss为后缀

三 表设计规范

• 单实例表个数必须控制在2000之内
• 单表分表个数必须控制在1024之内
• 表必须有主键,推荐使用UNSIGNED整数为主键

潜在坑 删除没有主键的表,若是是以row模式的主从架构,从库会挂住

• 禁止使用外键,若是要保证数据的完整性,应当由应用程序来实现

解读:外键使得表之间耦合性增长,影响update/delete等SQL性能,有可能形成死锁,高并发状况下 容易成为数据库瓶颈

• 建议将大字段,访问频率低的字段拆分到单独的表存储,分离冷热数据

 四 列设计规范

根据业务区分使用tinyint/int/bigint,分别占用1/4/8字节

根据业务区分使用char/varchar

解读

1 字段长度固定,或者长度近似的业务场景,适合使用char,可以减小碎片,查询性能高

2 字段长度相差较大,或者更新较少的业务场景,适合使用varchar,可以减小空间

根据业务区分使用datetime/timestamp

解读

前者占5个字节,后者占4个字节,存储年用year,存储日期用date,存储时间用datetime

必须把字段定义为NOT NULL 并设默认值

解读

NULL的列使用索引,索引统计,值更加复杂,MYSQL更难优化

NULL须要更多的存储空间

NULL只能采用IS NULL 或者IS NOT NULL 而在 = / != /in / not in 有大坑

使用INT UNSIGNED 存储IPv4  不使用char(15)

 使用varchar(20)存储手机号 不使用整数

解读

1 牵扯到国家代号,可能会出现 +/ - /() 例如+86

2 手机号不会进行数学运算

3 varchar能够模糊查询 例如like'138%'

使用tinyint替换ENUM

 解读ENUM增长新值要进行DDL操做

 

[转自微信公众号" 架构师之路"]