1.基础规范
- 所有表必须采用
innodb
存储引擎 - 所有表字符采用
utf8
, mysql8.0使用utf8mb4
- 所有表都需要添加注释
- 所有表必须显式指定主键
long
类型 自增1
禁止使用varchar
类型作为主键 - 单表数据量建议控制在
500W
以内 - 禁止存储
图
、文件
等大数据, 应存储它的路径
- 禁止从
测试
、开发
环境直连线上数据库 - 禁止存储
明文密码
- 禁止使用
外键约束
,允许外键关联
, 在业务端实现约束
2.命名规范
- 库名、表名、字段名必须使用
小写
字母,并采用下划线
分割 , 禁止使用驼峰式命名 - 库名、表名、字段名禁止
超过32
个字符。须见名知意 - 库名、表名、字段名禁止使用
mysql保留字
- 临时库、表名必须以
tmp
为前缀,并以日期
为后缀 , 日期格式yyyyMMddHHmmss
- 备份库、表名必须以
bak
为前缀,并以日期
为后缀 , 日期格式yyyyMMddHHmmss
- 库名以
d_
开头,表名以t_
开头,字段名以f_
开头不强制要求
3.库、表、字段开发设计规范
- 禁止使用
分区表
- 拆分大字段和访问频率低的字段,分离
冷热数据
- 注意大字段使用
TEXT(64kb)
、BLOB(64kb)
MediumText(16MB)
LONGTEXT(4GB)
,尽量不用 - 用
DECIMAL
代替FLOAT
和DOUBLE
存储精确浮点数 - 整形定义中不添加长度,比如使用
INT
,而不是INT[4]
- 对于长度基本固定的列,如果该列恰好更新又特别频繁,适合
char
varchar
虽然存储变长字符串,但不可太小也不可太大 ,默认255- 使用
timestamp
存储时间 timestamp占4字节,datetime占8个字节 - 存储ip最好用
int
存储而非char(15)
inet_aton()算法
, a.b.c.d 的 ip number = a * 256的3次方 + b * 256的2次方 + c * 256的1
次方 + d * 256的0次方。 - 不允许使用
ENUM
SET
boolean
类型, 使用TINYINT
来代替 - 所有字段必须定义为
NOT NULL
并设置默认值
避免使用NULL
字段, NULL 字段很难查
询优化,NULL字段的索引需要额外空间,NULL字段的复合索引无效 - 如果更改表结构会影响性能,需要找DBA进行联合评审
- 如无说明,表必须包含
create_time
和modify_time
字段,即表必须包含记录创建时间和修改时间的字段 - 如无说明,表必须包含
is_del
,用来标示数据是否被删除,原则上数据库数据不允许物理删除
4.索引规范
- 任何新的
select,update,delete
上线,都要先explain
- 索引个数限制 , 单张表的索引数量控制在
3个以内
, 避免冗余索引
, 超过3个需要经过DBA评估 - 没有特殊要求,使用
自增id
作为主键,主键不允许更新
- 对字符串使用
前缀索引
,前缀索引长度不超过8个字符
- 索引命名 :
非唯一索引
必须以idx_字段1_字段2
命名,唯一索引
必须以uniq_字段1_字段2 命名
,索引名称必须全部小写
5.sql语句设计规范
- 禁止直接
SELECT *
读取全部字段 - 能确定返回结果只有一条时,使用
limit 1
- 禁止在
where
条件列上使用函数
- 使用
like模糊匹配
,%不要放首位
- 涉及到
复杂sql
时,务必先参考已有索引设计,先explain - 使用
join
时,where条件尽量使用充分利用同一表上的索引
join不能连接超过3张表
- 少用
子查询
,改用join - 考虑使用
union all
,少使用union
,注意考虑去重 IN
的内容尽量不超过200个
, 使用到OR
的改写为用IN
- 避免使用
is null
,is not null
这样的比较 - 减少与数据库交互的次数,尽量采用
批量SQL
语句,例子:
INSERT INTO 表名() VALUES(),(),() | UPDATE … WHERE ID IN(10,20,50,…) - limit分页注意效率。
Limit越大,效率越低
。可以改写limit, 改写:
select id from tlimit 10000, 10; =>select id from t where id > 10000 limit 10
; - 使
预编译
语句,只传参数,比传递SQL语句更高效;一次解析,多次使用;降低SQL注入
概率 - 禁止使用
order by rand()
- 禁止单条SQL语句同时更新多个表
6.行为规范
导入导出数据
,执行sql脚本
需提前通知DBA
大批量更新
,如修复数据,需避开高峰期,并通知DBA
复杂sql上线
需提前通知DBA
- 重要项目的
数据库方案选型
和设计
需提前通知DBA
备注
在mysql中,uuid不适合做主键,特别是数据量大的情况下。主要有以下原因:
1. innodb 的非主键索引都将存一个主键,uuid 相比整数 id,索引大小增加很多;
2. uuid 主键比较肯定比 整数慢,另外非主键索引查找最终还要引用一次主键查找;
3. innodb 主键索引和数据存储位置相关(簇类索引),uuid 主键可能会引起数据位置频繁变动,严重影响性能.