mysql表设计规范
原创
命名规范
- 表名、字段名必须使用小写字母或数字，不使用英文缩写
长一点没关系，最好能让别的开发见名知意
- 主键索引名：pk字段名 唯一索引名：uk字段名 普通索引名： jdx_字段名
选择合适的字段类型
- 尽可能选择存储空间小的字段类型， tinyint smallint int bigint 从左往右开始选择
数据类型 | 特性 | 使用场景 |
|---|---|---|
| 1 字节有符号整数，取值范围为 -128 到 127 或者 0 到 255（无符号） | 储存布尔值、状态、标志等具有低范围值的数据 |
| 2 字节有符号整数，取值范围为 -32,768 到 32,767 或者 0 到 65,535（无符号） | 储存较小的整数值，如年份、订单数量等 |
| 4 字节有符号整数，取值范围为 -2,147,483,648 到 2,147,483,647 或者 0 到 4,294,967,295（无符号） | 储存常规整数值，如用户 ID、年龄、金额等 |
| 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涉及的列加索引
- 插入的数据过多，选用批量插入
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
