第四章:Schema与数据类型优化

1. 选择优化的数据类型

选择数据类型的原则

• 更小的通常更好:选择可以正确存储数据的最小数据类型
  • 小的数据类型消耗更少的内存、CPU;占用更少的磁盘
• 选用简单的数据类型:简单的数据类型通常需要更少的CPU周期来处理
  • 使用MySQL内建的类型来存储时间和日期
  • 使用整型存储IP地址
• 尽量避免null值：通常情況下使用not null，除非真的需要存出null值
  • null值使得索引、索引統計、值比較都变得复杂
  • 可为null的列需要更多的空间来存储
  • InnoBD使用单独的bit来存储null值

数字分为:整数和实数

1.1 整数类型

整数可以用:TINYINT、SMALLINT、INT、BIGINT类型来存储，分别占用8、16、24、32、64位的存储空间. 使用UNSIGNED属性标识整数，表示不可为负：

• TINYINT.UNSIGNED可以存储的范围是0-255，而TINYINT的范围是-128~127

MySQL可以为整数类型指定宽度,例如INT(11),对于大多数应用是没有意义的,他不会限制值的合法范围,只是规定了MySQL的客户端来显示字符的个数,对于存储来说INT(11)和INT(20)占用的空间是相同的.

1.2 实数类型

实数是带有小数部分的数字,实数类型也不一定是用来存小数,可以用decimal来存储比bigint还大的整数.

MySQL既支持精确类型也支持不精确类型:

• float和double类型支持使用标准的浮点运算进行近似计算.float占用4个字节,double占用8个字节,MySQL使用double进行内部的浮点数计算,
• decimal用于存储精确的小数,支持精确计算;此外,CPU不支持decimal运算,因此MySQL服务层实现了decimal的精确计算,相对而言,CPU直接计算浮点数,因此更快.decimal占用的空间要比double多.

许多方法可以指定浮点列的精度,这样MySQL会悄悄使用不同的数据类型,或者在存储时进行取舍,因此建议只指定数据类型而不指定精度.鉴于空间和计算开销,应该只在对小数进行计算的场景下才使用decimal.

1.3 字符串类型

• MySQL支持多种字符串类型,每种类型还有很多变种.
• varchar和char是两种主要的字符串数据类型,这两种数据类型的存储方式和存储引擎有关.

1.3.1 varchar

• varchar用于存储可边长的字符串,它仅使用需要的空间来存储数据-->节省空间
• varchar使用额外的1个或者2个字节来存储数据长度
• 节省了空间也带来了性能提升,但是执行update时可能会使时间变长
• 适合用varchar存储的场景:
  • 字符串列的最大长度比平均长度大的多
  • 列的更新很少
  • 使用了复杂字符集(UTF-8)

1.3.2 char

• char是定长的,MySQL根据定义的字符串长度分配固定的空间
• char类型会根据需要使用空格填充以方便比较,较varchar而言不容易产生碎片
• char适合存储短的或者长度接近一个固定值的串
  • 存储密码的MD5值
  • 存储二进制数据并需要比较时,char会更快
• 对于任意存储引擎,填充和截取空格的结果都是一样的,因为是在服务层实现的

1.3.3 blob和text类型

• blob和text是MySQL为很长的字符串设计的类型,分别采用二进制和字符串来存储.
• 数据过长是,这两个类型在Innodb引擎中使用外部区域来存储,在行内使用1-4字节的指针指向这个外部区域.

1.3.4 使用枚举类型代替字符串

• MySQL在存储枚举时非常紧凑,会根据列表值将的数量压缩到一个或两个字节大小,MySQL在映射关系"查找表"中保存"数字-字符串"的关系.

mysql>create table enum_test(
    e ENUM('fish','apple','dog')not null
);
mysql> insert into enum_test(e)values('fish','dog','apple');

这三行数据实际上存储为整数:

mysql> select e+0 from enum_test;

+---+
|e+0|
+---+
|  1|
|  3|
|  2|
+---+

• 使用美剧不好的地方在与字符串列表时固定的,需要修改时必须将表删了重建.
• 某些情况下,char/varchar和枚举列关联会导致性能下降.

1.4 日期和时间类型

MySQL能存储的最小时间单位是秒,但是也可以使用微秒级别的粒度进行临时运算.

1.4.1 DATETIME

• 保存大范围的值,从1001年到9999年,精度位秒.
• 格式:YYYYMMDDHHMMSS,8个字节存储

1.4.2 TIMESTAMP

• 和UNIX时间戳一样保存了1970年1月1日午夜以来的秒数.
• 占用4个字节的空间,只能保存1970-2038年
• 显示的值依赖时区
• 默认值为null,插入时没有指定默认值使用当前时间为这列的值

此外,可以用bigint来保存更小粒度的时间值

1.5 位数据类型

? MySQL之后少数的类型使用位来存储数据,例如bit和set而不管底层储存格式和方式如何,从技术上来说都是字符串.

1.6 选择标识符

标识列可能被用来与其他列比较,或者通过标识列寻找其他列,标识列也可能被用在外键.

在满足值的范围,并且保证未来的增长空间时应选择最小的 数据类型来作为标识列的类型:

• 整数类型通常是比较好的类型,可以使用auto_increament.
• 一般情形下,不建议使用枚举和set,这两者只适合存储固定的信息
• 避免使用字符串,因为比较消耗空间并且比较时较整数类型慢

2.MySQL在schema中设计中的陷阱

• 太多的列
  • MySQL的存储引擎API工作时需要在服务层和存储引擎层之间通过行缓冲格式拷贝数据,然后在服务层将缓冲内容解码成各个列,解码的过程时异常消耗性能的.
• 太多的关联
  • 在MySQL下不能很好的使"实体-属性-值"(EAV)的设计模式工作.
  • MySQL限制了每个关联操作最多61张表,但EAV数据库需要很多自关联.
  • 一些经验表明,12个表以内的关联MySQL工作效率最高.
• 全能的枚举
  • 防止过度使用枚举,因为枚举的天然不支持修改,一旦要修改代价会很高.
• 变相的枚举
  • 集合set列允许一个或者多个值,这时候容易混乱:

    create table ...(is_default set('Y','N') not null default'N');

    如果这里真假两种情况不会同时出现,那么使用枚举会更加合适.

• 非此此发明的null
  • 建议一般不要使用null值,即便真要用,可以使用0或者某些特定的值来代替,如空字符串.

3.范式和反范式

在范式化的数据库中所有数据出现且仅出现一次,而反范式的数据中,每个事实数据可能会出现多次,信息冗余.

3.1 范式的优点和缺点

写密集型的表按照范式规范设计性能会更好!

• 范式化的更新更快
• 数据较好的范式化时,很少的数据会冗余,也就是说只需要更新很少的数据
• 范式化的数据很少冗余,占用的空间少,就可以更好更快的放在内存操作
• 冗余较少时distinct和group by使用频率就会下降

3.2反范式的优点和缺点

• 反范式的数据都在一张表中,可以很好的避免关联.
• 如果不需要关联,则针对大部分查询慢(即使没有索引)需要全表扫描,那么当数据比内存大时全表扫描可能要比关联快很多.

3.3 混用范式和反范式

• 最常见的反范式化设计是复制或者缓存,在不同的表中存储相同的某个列.
• MySQL5.0之后可以用触发器更新缓存.

4.缓存表和汇总表

有时候提升性能最好的方法是在表中保存一写衍生的冗余的数据,但在某些时候,也需要创建一张完全的汇总表或者缓存表.

• 缓存表:可以比较简单的从schema中其他表中获取(每次获取速度表较慢)数据的表(逻辑上冗余的表)
• 汇总表:保存的是使用group by语句聚合数据的表(不是逻辑上冗余的数据).

5.总结

• 尽量避免过度设计
• 使用小和简单的合适数据类型,尽量避免使用null值
• 尽量使用相同的数据类型存储相似或者相关的列,尤其是关联条件中的列
• 注意可变长字符串
• 尽量使用整型定义标识列
• 避免使用MySQL已经遗弃的特性
• 小心的使用枚举和set,最好避免使用bit
• 范式是好的,但是很多时候反范式也是有必要的,这回带来好处

原文地址：https://www.cnblogs.com/mydailycoding/p/12348326.html