Protogalaxy

Planet #0

数据库设计与性能优化笔记整理

数据库设计范式:

总的设计思路大致为:消除数据冗余,避免插入/删除/修改异常

相关名词解释:

  • 码:关系中的某个属性或某几个属性的组合,用于区分数据库中每条记录
  • 函数性依赖:在一张表中,在属性/属性组中的X值确定的情况下,必能确定属性Y的值,这里的函数不是一种特定的数字关系,而是一种抽象的关系概念,比如学号→姓名。
  • 传递函数依赖:有传递性的依赖关系,例如A→B,B→C,则C与A具有传递函数依赖关系。

1NF:即表中的所有属性都不可再分割,1NF为所有关系型数据库的基本要求。

2NF:在1NF的基础上,消除非主属性对于码的部分函数性依赖。

3NF:在2NF的基础上,消除非主属性对于码的传递函数依赖。

范式的优点与缺点:

  • 范式的更新操作通常比反范式要快。
  • 当数据较好的范式化时,就只有很少甚至没有冗余数据,所以修改所带来的开销会相对较少。
  • 范式化的表通常体积较小,可以更好地放在内存中,所以执行操作会更快。
  • 冗余数据较少意味着在查询检索时会更少需要DISTINCT或者GROUP BY语句。

范式化设计的schema的缺点是通常需要关联。稍微复杂一些的查询语句在符合范式的schema上可能需要至少一次甚至更多关联。这不但代价昂贵,也可能使一些索引策略失效。例如,范式化可能将列存放在不同的表中,而这些列如果在一个表中本可以属于同一个索引。

反范式的优点与缺点:

反范式化的schema因为所有的数据都在一张表中,所以可以很好的避免关联。

如果不需要关联表,则对大部分查询最差的情况–即使表没有使用索引–是全表扫描。当数据比内存大时这可能比关联要快得多,因为这样避免了随机I/O。

关于使用自增主键与使用UUID作为主键的主键策略对比(InnoDB):

  • 首先介绍InnoDB的主键索引方式-聚簇索引:聚簇索引定义了表中数据的物理存储顺序,相邻主键的物理位置也是相邻的,按照大小排序。由于·UUID为无序数列,所以在索引时会降低索引性能,造成巨大的IO压力。
  • 存储空间方面:UUID由于长度的关系,在数据量上升时会造成一定的存储压力
  • 数据独立性方面:自增主键在合并表的时候可能会出现主键重复的情况,而UUID不仅是表独立的,而且是库独立的,在数据库切分与合并时比较方便
  • 分布式存储:由于UUID的独立性,相比自增主键而言更适合与分布式存储

关于twitter开源分布式自增ID算法snowflake:

Github:https://github.com/twitter/snowflake

 

部分内容摘自《高性能MySQL》,在这里也向想了解更多关于数据库设计优化的小伙伴推荐这本书,写的还挺不错的。

发表评论