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');如果这里真假两种情况不会同时出现,那么使用枚举会更加合适.
- 集合set列允许一个或者多个值,这时候容易混乱:
- 非此此发明的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