Mysql中分区和分表有什么区别,各自的优缺点是什么

Mysql中分区和分表有什么区别,各自的优缺点是什么,第1张

数据库表中数据量能够被预测到将会非常大,或者已经拥有庞大的数据时,我们应该选择分表或者分区(即使用多个数据库)来解决数据访问时的性能问题。如果单机的cpu能够承受站点的并发数,应该选择分表的方式,因为分表相对简单,容易实现scale,而且涉及到多表连接时,分区是不能直接使用join的。但如果站点并发数太大,需要多个cpu来访问多个数据库是无疑的,这时需要选择分区的方式。

详细参考:>

你这种方式可以实现,但查询会变得很复杂,而且很多存储过程可以都不能用了。

另一种方式就是纵向分开A表。

就是说把A表分为AA和AB两个表。依据就是AA里面是小的,经常被查询用到的列,比如日期,ID。AB里面是大的,不经常查询的列比如text,xml,file 等。AA和AB通过外键联系。这样你的查询就不用跨很多分区,结果会快很多。

还有一个办法是把所有用到的列一起建一个索引,肯定会加快查询,但这种方式会增加很多硬盘开销,同时降低插入和更改的效率。

一句题外话:

数据库管理中最好不要轻易做这么大的改动。这个查询可能很慢,但如果用户不是经常查或者已经习惯了,不如不改。

为了保证系统并发性能,OceanBase暂时不支持更高的隔离级别。OceanBase跟Oracle和MySQL一样,都属于关系数据库,不过OceanBase是一款基于分布式架构的关系数据库,还是一款原生的分布式数据库,并不是分库分表中间件架构的数据库,是由阿里巴巴和蚂蚁金服自主研发、完全不依赖于任何开源项目的数据库产品。2019年OceanBase得到海外权威机构TPC-C认证,测试结果超过6088万tpmC,登上行业性能榜首,是Oracle的两倍。

大数据量实时统计排序分页查询的瓶颈不是函数(count,sum等)执行,

不是having, 也不是order by,甚至不是表join, 导致慢的原因就在于“数据量太大本身”

就是将表划分为M份相互独立的部分,可以是分表,也可以是不分表但冗余一个取模结果字段

实际结果是不分表比分表更加灵活,只需稍加配置,就可以动态切分大表,随意更改M的大小。

将1条慢sql(大于30秒)拆分成为N条查询速度巨快的sql(单条sql执行时间控制在20毫秒以内)

然后再web应用中以适当的线程数去并发查询这些执行时间快的N条小sql再汇总结果

第一步查询中去并发执行这N条小sql, 只取排序字段和标识字段,其他字段一律丢弃

汇总结果后定位出当前页面要显示的pageNum条数据,再进行第二步查询,取出页面上需要展示的所有字段

PS:这一点是至关重要的,其他几点都可以不看,这点是最关键的。慢慢解释一下:

有三种方式统计所有的记录,

a) 第一种方式是把数据库中所有记录(只取排序字段和标识字段并且不做任何sum,count having order by等 *** 作)

全部拉到web应用中,在web应用中完成所有的计算

b) 第二种方式是把数据库中所有记录做sum count having等 *** 作之后的所有行数拉到web应用中,在web应用中完成剩余计算

c) 第三种方式是把数据库中所有记录做sum count having order by等 *** 作之后把limit后的数据拉到web应用中,

在web应用中对limit后的数据再计算

显然,第一种方式 数据库什么活都不做只取数据 是不可行的。以lg_order_count_seller为例,1500万行,

如果只算id, seller_id和order_count 这三个bigint类型,至少需要拉831500 0000 = 360000000=340M,

拉到内存中之后存储需要8415000000= 460M,这还不算List是的2的n次方这个特点和计算排序等的内存开销,

不仅数据库与web应用机器IO扛不住,就是应用自身恐怕也要OOM了。

第二种方式,所有记录做sum count having等 *** 作之后,由于是group by seller_id的,总得数据量变为100万(就是卖家总数),

这样子一来,共需要拉83100 0000 = 23M,拉到内存之后,需要84100 0000 = 30M, 再算上List是的2的n次方这个特点和

计算排序等的内存开销也不会超过100M, IO的时间和内存开销勉强可以考虑接受。

第三种方式,所有记录做sum count having order by等 *** 作之后把limit后的数据拉到web应用中,因为做了limit,所以,

数据量很小了,无论是IO还是内存开销都已经很小了。可以忽略。

综合以上三种,第三种方式适用于页面的前n页和后n页,因为这个limit的数据量随着页数的增大而增大,

当大到每个切分后的小表的数据量时就转为第二种方式了。

第二种方式适用于页面的第[n+1, totaoPageNum-n]页。

① 问题描述:

优化之前,还是是一条大慢sql查询时,由于数据库排序是稳定排序,

所以当两条记录排序字段值相同时他们在页面上的页码位置是固定的。

优化之后,当并行执行这N条小sql时,由于无法控制这些小sql的先后执行顺序,

导致在web应用中当两条记录的排序字段值相同时在页面上的页码位置是随机的。

② 解决办法:

除了拉标识字段(seller_id)和排序字段(order_count_sum)之外,再取一个unique(id)的字段,当两条记录的排序字段值相同时,

再用这个unique的字段(在卖家监控中这个字段是id)进行第二次排序这样就解决了排序不稳定的问题。

③ 也许,看到这里会有疑问,为什么不用seller_id?seller_id也是唯一, 这样子不是少取id这个字段,减少IO了?

seller_id虽然也是唯一,可以辅助排序,但是不要忘记数据库的排序规则是:

如果两列的值相等,那么序号在前的排在前面,这里的序号就是主键(自动生成,autoincrement),

如果用seller_id的话还是不能保证排序的稳定性,只能用主键id

把数据库的连接,扫表,计算等资源优先让给用户关注的主要元素,次要元素可等主要元素加载完成之后再加载。

反应在卖家监控页面中,查数据和查页页码的sql语句基本相同,是在竞争同一资源,

所以,需要做一个策略,优先把资源让给查数,数据查完之后再去查页码。

由于多线程取数据并没有从本质上提高数据库性能,所以必须针对大数据量实时统计排序分页查询做限流

我这里打个比方:食堂有6个窗口,物流团队吃饭要买6个菜,平均每买1个菜需要1分钟的时间,

如果派我一个人去一个窗口买的话需要6分钟的时间

假如派6个人分别去6个窗口买这6个菜,只需要1分钟的时间

但是,如果除了物流团队,再来其他5个团队呢,也就是说6个团队每个团队买6个菜共买36个菜,

这样子有的团队先买完,有的团队后买完,但平均时间还是6分钟。本质上没有变化。

所以,对于特定的查询条件,必须进行限流。让每分钟至多有6个团队买菜,这样子能使得情况变得不至于太糟糕。

这一点从目前来看只能是展望了,比如mysql数据库换更为强大的oracle数据库,

或更换InnoDb引擎为其他,或更换SATA硬盘为SSD 。。。。。。

相同的查询条件,原来一个页面查询时间由于超过60秒超时了,根据1-6点建议优化之后,查询时间变为2秒至35秒之间。

以上就是关于Mysql中分区和分表有什么区别,各自的优缺点是什么全部的内容,包括:Mysql中分区和分表有什么区别,各自的优缺点是什么、oracle数据库,搜索百万级别数据分页优化问题、sql 大量数据分表查询等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9341996.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-27
下一篇 2023-04-27

发表评论

登录后才能评论

评论列表(0条)

保存