mysql表设计规范

命名规范

• 表名、字段名必须使用小写字母或数字，不使用英文缩写

长一点没关系，最好能让别的开发见名知意

• 主键索引名：pk_字段名 唯一索引名：uk_字段名 普通索引名： jdx_字段名

选择合适的字段类型

• 尽可能选择存储空间小的字段类型， tinyint smallint int bigint 从左往右开始选择

数据类型	特性	使用场景
tinyint	1 字节有符号整数，取值范围为 -128 到 127 或者 0 到 255（无符号）	储存布尔值、状态、标志等具有低范围值的数据
smallint	2 字节有符号整数，取值范围为 -32,768 到 32,767 或者 0 到 65,535（无符号）	储存较小的整数值，如年份、订单数量等
int	4 字节有符号整数，取值范围为 -2,147,483,648 到 2,147,483,647 或者 0 到 4,294,967,295（无符号）	储存常规整数值，如用户 ID、年龄、金额等
bigint	8 字节有符号整数，取值范围为 -9,223,372,036,854,775,808 到 9,223,372,036,854,775,807 或者 0 到 18,446,744,073,709,551,615（无符号）	储存大整数值，如主键、订单号等

• 小数类型，如金额，选择decimal

一定要选用bidecimal，shigen在这个上边填了前人写的巨大的bug！

• 存储的字符串长度几乎相等，使用char定长字符串类型
• varchar可变长度的字符串，长度不要超过5000
• 如果存储的值太大，将字段类型修改为text，同时单独一张表，用主键与之对应

选择合适的字段长度

优化数据的存储空间，如果字段长度设置过大，会浪费存储空间，而设置过小可能导致数据截断或者插入失败。

优先考虑逻辑删除，而不是物理删除

• 物理删除数据恢复困难
• 物理删除会使主键不再连续
• 核心业务表的数据不建议做物理删除

每个表都需要的通用字段

不一样的通用字段的英文不一样叫法，但是都是规范中建议的

id	意义	必须
create_time	创建时间	必须
update_time	修改时间	必须
version	乐观锁	非必须
reamrk	数据标注	非必须
modified_by	修改人	非必须
creator	创建人	非必须

一张表的字段不要过多

字段不要超过20个，表的字段过多，表中保存的数据可能会很大，查询的效率会降低。大表拆成小表，让他们的主键相同即可。

尽可能使用 not null定义字段

将字段设置成空字符串或者常量值

• not null防止出现空指针的问题
• null值存储也需要额外的空间，导致比较运算更为复杂，是优化器难以优化sql
• null值可能会导致索引失效

设计索引

有查询条件的字段，一般要加索引

• 单表的索引不超过5个
• 区分度不高的字段，不添加索引（性别）
• 避免索引失效的情况（mysql的内置函数）
• 索引过多，选用联合索引优化

不使用外键关联

• 使用外键存在性能问题、并发死锁问题、使用起来不方便等。每次delete、update都必须考虑外键约束
• 分库分表不能使用

不建议使用存储过程、触发器

存储过程：

已预编译为一个可执行过程的一个或多个sql语句

触发器：

一段代码，当触发某个事件时，自动执行这些代码

• 可以用数据库中相关联的表实现级联修改

• 实现监控某张表中的某个字段的改变而需要做出相应的处理

• 生成某些业务的编号

• 滥用造成数据库和应用程序的维护困难

• mysql对于存储过程、触发器等还不是很成熟，没有完善的出错记录处理，不建议使用

sql编写的优化经验

• 查询尽量不要使用select *
• 查询的结果只要一条或者只要最大/小的一条记录，建议使用limit 1
• 避免where子句中使用or来连接条件
• 优化limit深度分页问题
• where条件限定要查询的数据，避免返回多余的行
• 避免在where子句中对字段进行表达式操作
• 对索引优化，应考虑在where及order by涉及的列加索引
• 插入的数据过多，选用批量插入