一,基础规范
- 表存储引擎必须使用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操作
[转自微信公众号" "]