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涉及的列加索引
  • 插入的数据过多,选用批量插入

你可能感兴趣的:(mysql,设计规范,数据库)