MySQL调优-高性能业务表结构设计
| 阿里云国内75折 回扣 微信号：monov8 |
| 阿里云国际，腾讯云国际，低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号：monov8 飞机：@monov6 |
目录
前言记录
产品上线之前建议遵守范式化。当产品上线之后如果产品出现并发 性能问题后再进行考虑数据库表性能优化然后进行反范式化表优化性能。
数据库表设计
良好的表结构设计是高性能的基石应该根据系统将要执行的业务查询来设计这往往 需要权衡各种因素。糟糕的表结构设计会浪费大量的开发时间严重延误项目开发周 期让人痛苦万分而且直接影响到数据库的性能并需要花费大量不必要的优化时间效果往往还不怎么样。 在数据库表设计上有个很重要的设计准则称为范式设计。
范式设计
什么是范式
范式来自英文Normal Form简称NF。MySQL是关系型数据库但是要想设计—个好的关 系必须使关系满足一定的约束条件此约束已经形成了规范分成几个等级一级比 一级要求得严格。满足这些规范的数据库是简洁的、结构明晰的同时不会发生插入 (insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟不仅给数据库 的编程人员制造麻烦而且面目可憎可能存储了大量不需要的冗余信息。 目前关系数据库有六种范式第一范式1NF、第二范式2NF、第三范式3NF、 巴斯-科德范式BCNF、第四范式(4NF和第五范式5NF又称完美范式。满足最 低要求的范式是第一范式1NF。在第一范式的基础上进一步满足更多规范要求的称为 第二范式2NF其余范式以次类推。一般来说数据库只需满足第三范式(3NF就行 了。
数据库设计的第一范式
定义 属于第一范式关系的所有属性都不可再分即数据项不可分。
理解 第一范式强调数据表的原子性是其他范式的基础。例如下表
name-age列具有两个属性一个name,一个 age不符合第一范式。
把它拆分成两列
上表就符合第一范式关系。但日常生活中仅用第一范式来规范表格是远远不够的依然 会存在数据冗余过大、删除异常、插入异常、修改异常的问题此时就需要引入规范化 概念将其转化为更标准化的表格减少数据依赖。
实际上1NF是所有关系型数据库的最基本要求你在关系型数据库管理系统 RDBMS例如SQL ServerOracleMySQL中创建数据表的时候如果数据表的设计 不符合这个最基本的要求那么操作一定是不能成功的。也就是说只要在RDBMS中已经 存在的数据表一定是符合1NF的。
数据库设计的第二范式
第二范式2NF是在第一范式1NF的基础上建立起来的即满足第二范式2NF必 须先满足第一范式1NF。
第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一的进行区分。通常在实现来说需要为表进行加上一个列以此存储各个实例的唯一标识。例如员工信息表中加上了员工 编号emp_id列因为每个员工的员工编号是惟一的因此每个员工可以被惟一区 分。这个惟一属性列被称为主关键字或主键、主码。
也就是说要求表中只具有一个业务主键字段而且第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。什么意思呢
有两张表订单表产品表。
但是订单表此时存在两个主键一个订单表ID一个产品ID违背了第二范式。
一个订单有多个产品所以订单的主键为【订单ID】和【产品ID】组成的联合主键这样两个组件不符合第二范式而且产品ID和订单ID没有强关联因此把订单表进行拆分为订单表与订单与商品的中间表。
数据库设计的第三范式
指每一个非主属性既不部分依赖于也不传递依赖于业务主键字段。也就是在第二范式的基础上进行消除了非主键字段对主键字段的传递依赖。例如存在一个部门信息表其中每个部门有部门 编号dept_id、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就 不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表则根据第三范式3NF也应该构建它否则就会有大量的数据冗余。
其中
产品 ID与订单编号存在关联关系
产品名称与订单编号存在关联关系
产品ID与产品名称存在关联关系
订单表里如果如果产品ID发生改变同一个表里产品名称也要跟着改变这样不符合第三范式应该把产品名称这一列从订单表中删除。
范式说明
真正的数据库范式定义上相当难懂比如第二范式2NF的定义“若某关系R属于第 一范式且每一个非主属性完全函数依赖于任何一个候选码则关系R属于第二范 式。”这里面有着大堆专业术语的堆叠比如“函数依赖”、“码”、“非主属 性”、与“完全函数依赖”等等而且有完备的公式定义。
反范式设计
什么叫反范式化设计
完全符合范式化的设计真的完美无缺吗很明显在实际的业务查询中会大量存在着表的 关联查询而大量的表关联很多的时候非常影响查询的性能。
所谓得反范式化就是为了性能和读取效率得考虑而适当得对数据库设计范式得要求进行违反。允许存在少量得冗余换句话来说反范式化就是使用空间来换取时间。
反范式设计-商品信息
下面是范式设计的商品信息表
商品信息和分类信息经常一起查询所以把分类信息也放到商品表里面冗余存放。
范式化和反范式总结
范式化设计优缺点
1、范式化的更新操作通常比反范式化要快。
2、当数据较好地范式化时就只有很少或者没有重复数据所以只需要修改更少的数据。
分析1和2因为范式化设计的表表中是没有冗余字段的。
但是对于反范式化的表我举一个例子对于商品详情shop_description这个字段可能在用户表中建立一份在商家表中也建立一份有可能在商品记录表中又建立一份。所以当商品详情shop_description这个字段进行修改时我们需要在多个表中进行更改shop_description这个字段的数据要修改的表多所以范式化的更新操作通常要比反范式化要快。当数据较好地范式化时就只有很少或者没有重复数据所以只需要修改更少的数据。
3、范式化的表通常更小可以更好地放在内存里所以执行操作会更快。
分析3由于表空间是占用内存空间是随机的所以内存碎片化一定十分严重。
范式化的表通常无冗余字段所以表相对比较小所以更容易放在碎片化的内存中。因为表过大时占用的内存的空间过大所以此时表占内存过大时就无法轻松的去存储到这碎片化的内存空间了
4、很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。在非 范式化的结构中必须使用DISTINCT或者GROUPBY才能获得一份唯一的列表因为一个相同的字段可能会在多个表中进行创建但是如果是一 张单独的表很可能则只需要简单的查询这张表就行了。
范式化设计的缺点是通常需要关联。稍微复杂一些的查询语句在符合范式的表上都可能需要至少一次关联也许更多。这不但代价昂贵也可能使一些索引策略无效。例如 范式化可能将列存放在不同的表中而这些列如果在一个表中本可以属于同一个索引。
反范式化设计优缺点
1、反范式设计可以减少表的关联
2、可以更好的进行索引优化。 反范式设计缺点也很明显1、存在数据冗余及数据维护异常2、对数据的修改需要更 多的成本。
实际工作中的反范式实现
性能提升-缓存和汇总
范式化和反范式化的各有优劣怎么选择最佳的设计? 请记住小孩子才做选择我们全都要小孩才分对错大人只看利弊。
而现实也是完全的范式化和完全的反范式化设计都是实验室里才有的东西在真实世 界中很少会这么极端地使用。在实际应用中经常需要混用。
最常见的反范式化数据的方法是复制或者缓存在不同的表中存储相同的特定列。
比如从父表中冗余一些数据到子表中。前面我们看到的分类信息放到商品表里面进行冗余存放就是最典型的例子。
缓存衍生值也是有用的。如果需要显示每个用户发了多少消息可以每次执行一个对用 户发送消息进行count的子查询来计算并显示它也可以在user表用户中建一个消息发送 数目的专门列每当用户发新消息时更新这个值。
有需要时创建一张完全独立的汇总表或缓存表也是提升性能的好办法。“缓存表”来表 示存储那些可以比较简单地从其他表获取但是每次获取的速度比较慢数据的表例 如逻辑上冗余的数据)。而“汇总表”时,则保存的是使用GROUP BY语句聚合数据的表。
在使用缓存表和汇总表时有个关键点是如何维护缓存表和汇总表中的数据常用的有 两种方式实时维护数据和定期重建这个取决于应用程序不过一般来说缓存表用实时维护数据更多点往往在一个事务中同时更新数据本表和缓存表汇总表则用定期重建更多使用定时任务对汇总表进行更新。
性能提升-计数器表
计数器表在Web应用中很常见。比如网站点击数用户的朋友数文件下载次数等。对于高并发下的处理首先可以创建一张独立的表存储计数器这样可以使得计数器表小且快并且可以使用一些更高级的技巧。
比如假设有一个计数器表只有一行数据记录网站的点击次数网站的每次点击都会导致对计数器进行更新问题在于对于任何想要更新这一行的事务来说这条记录上都有一个全局的互斥锁。这会使得这些事务只能串行执行会严重的限制系统的并发能力。
怎么改进呢可以将计数器保存在多行中每次随机选择一行进行更新操作。在具体实现上可以增加一个槽slot字段然后预先在这张表增加100行或者更多数据当对计数器进行更新时选择一个随机的槽slot进行更新即可。
这种解决思路其实就是写热点的分散在JDK的JDK1.8中新的原子类LongAdder也是这种 处理方式而我们在实际的缓冲中间件Redis等的使用、架构设计中可以采用这种写热 点的分散的方式当然架构设计中对于写热点还有削峰填谷的处理方式这种在MySQL的 实现中也有体现我们后面会讲到。
反范式设计-分库分表中的查询
例如用户购买了商品,需要将交易记录保存下来,那么如果按照买家的纬度分表,则每个买家的交易记录都被保存在同一表中, 我们可以很快、 很方便地査到某个买家的购买情况, 但是某个商品被购买的交易数据很有可能分布在多张表中, 査找起来比较麻烦 。
反之, 按照商品维度分表, 则可以很方便地査找到该商品的购买情况, 但若要査找到买家的交易记录, 则会比较麻烦。
所以常见的解决方式如下。
( 1 ) 在多个分片表查询后合并数据集, 这种方式的效率很低。
( 2 ) 记录两份数据, 一份按照买家纬度分表, 一份按照商品维度分表
( 3 ) 通过搜索引擎解决, 但如果实时性要求很高, 就需要实现实时搜索
在某电商交易平台下, 可能有买家査询自己在某一时间段的订单, 也可能有卖家査询自 已在某一时
间段的订单, 如果使用了分库分表方案, 则这两个需求是难以满足的, 因此, 通用的解决方案是, 在交
易生成时生成一份按照买家分片的数据副本和一份按照卖家分片的数据副本,查询时分别满足之前
的两个需求,因此,查询的数据和交易的数据可能是分 别存储的,并从不同的系统提供接口。
