六.schema设计

11 篇文章 0 订阅
6 篇文章 0 订阅

一.库表的设计范式

  • 第一范式:表中的任何字段不可拆分
  • 第二范式:表中的非主属性都要完全依赖于主键
  • 第三范式:满足第二范式的基础上,表中的非主属性不能相互依赖

二.选择更优的数据类型

1.原则

  • 更小的通常更好,前提是存储范围不被低估
  • 简单为好,简单数据类型处理起来更高效
  • 避免存储NULL,可以为NULL的列使得索引、索引统计和值都比较复杂

2.字段类型

  • 整型

    • tinyint:8
    • mediumint:16
    • int:32
    • bigint:64
    • unsingned修饰:范围扩大一倍

    int(1)和int(32) 的存储和计算是相同的,只是长度只是规定了交互工具展示的位数

  • 实数类型

    • 浮点运算
      • float:32位
      • double:64位
    • 精确计算:decimal
  • 字符类型

    • varchar:可变字符串,需要1~2位存储长度,适用场景:
      • 最大长度远大于最小长度
      • 列的更新很少
      • 适用了复杂的字符集,每个字符的字节数不同
    • char:固定长度字符串,未完全填充时使用空格,适用场景:
      • 非常短的字符串,无需而外存储长度
      • 所有字符串长度几乎相同
      • 经常修改的数据,比varchar好,不容易出现碎片
    • 大文本类型
      • blob:二进制,没有排序规则和字符集
      • text:有排序规则和字符集
    • 枚举类型:存储更为紧凑,同时会将值存为整数
    • 日期和时间类型
      • datetime:1000~9999,精度微秒
      • timestamp:1970年1月1日以来的秒数,依赖于时区(服务器、操作系统、客户端均可设置),插入和更新时会默认更新第一列timestamp值为当前时间
    • 压缩位数据类型bit,二进制而非数字类型
    • json数据类型,需要存储额外的字符,占用空间更大

三.设计陷阱

  • 避免太多列,服务器和存储引擎之间通过行复制进行工作,服务器将行解码为列,列过多时解码的CPU消耗较高
  • 避免太多连接:连接过多时会成为并发的瓶颈
  • NULL不是虚拟值,可以使用0、特殊字符、空字符串进行代替
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值