mysql单库负载过高的处理方式

mysql单库负载过高的处理方式,第1张

请点击输入图片描述(最多18字)

经常混迹于技术社区,频繁看到这个题目,今天干脆在自己博客重复一遍解决办法:

针对mysql,sqlserver等关系型数据库单表数据过大的处理方式

如果不是阿里云分布式数据库 DRDS 那种多机器集群方案的话: 先考虑表分区 ;然后考虑分表 ;然后考虑分库。

这个题目是我所经历过的,我做的是GPS应用,早期版本就是选用的关系型数据库Sql Server。当时我选取的方案就是第一种:表分区。 表分区的优势是,如果表结构合理,可以不涉及到程序修改。也就是说,对程序来讲依然是单表读写的效果!

所有轨迹数据存入到一个巨大的表里。有多大呢?

最大存储量超过10亿行。具体数值应该是12亿多点,由于系统设计为只存储30天轨迹,所以线上期间最大存储只到这个数,再后来采用云架构,上云替换成非关系性数据库,获得了更高的写入性能和存储压缩能力。   每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops,距离系统设计的压测指标3000还有一大截

这张大型单表设计要点:(一个聚集索引用于写入,一个联合索引用于查询,没有主键,使用表分区)

明确主键用途:

真的需要查询单行数据时候才需要主键!

我采用无主键设计,用于避免写入时候浪费维护插入数据的性能。最早使用聚集的类似自增的id主键,压测写入超过5亿行的时候,写入性能缩减一半

准确适用聚集:

写入的数据在硬盘物理顺序上是追加,而不是插入!

我把时间戳字段设置为聚集索引,用于聚集写入目的设计。保证硬盘上的物理写入顺序,不浪费性能用于插入数据

职责足够单一: 

用于精准索引!

使用时间+设备联合索引,保证这张表只有一个查询用途。保证系统只有一种查询目的:按照设备号,查询一个时间段的数据。

精确的表分区:

要求查询时候限定最大量或者最大取值范围!

按天进行表分区,实现大数据量下的高效查询。这里是本文重点,按照聚集索引进行,可以让目标数据局限在更小的范围进行,虽然单表数据上亿,但是查询基本上只在某一天的的几千万里进行索引查询

每张表会有各自的特点,不可生搬硬套,总结下我这张表的特点:

只增,不删,不改!

关于不删除中:每天使用作业删除超过30天的那个分区数据除外,因为要清空旧的表分区,腾出新的表分区!

只有一个业务查询:只按照设备编码查询某个时间段

只有一个运维删除:删除旧的分区数据

这张表,是我技术生涯中进步的一个大阶梯,让我我体会到了系统架构的意义。

虽然我的这张举行表看似只有4个关键点,但是这四个非常精准的关键点设计,耗费了我一个月之久!正是这么足够精准的表结构设计,才撑起了后来压测并发量超过3000的并发写入量!压测的指标跟数据库所在的硬盘有直接关系,当时选取的硬盘是4块10000转的SAS盘做了Raid10的环境

关于后来为什么没有更高的实际应用数值,是因为系统后来改版为云架构,使用了阿里云,更改为写入性能更高的非关系型数

您好,很高兴为您解答。

第一先限制Innodb的并发处理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看机器压力,如果

非常大,先改成16让机器的压力下来,然后慢慢增达,适应自已的业务.

处理方法: set global innodb_thread_concurrency=16

第二: 对于连接数已经超过600或是更多的情况,可以考虑适当的限制一下连接数,让前端报一下错,也别让DB挂了.

DB在了,总是可以用来加载一下数据,当数据加载到了nosql里了,慢慢的DB压力也会降下来的.

限制单用户连接数在500以下. 如:

set global max_user_connections=500

(MySQL随着连接数的增加性能会是下降的,这也是thread_pool出现的原因)

另外对于有的监控程序会读取information_schema下面的表的程序可以考虑关闭下面的参数

innodb_stats_on_metadata=0

set global innodb_stats_on_metadata=0

这个参数主要防止对读取information_schema时造成大量读取磁盘进行信息统计(如果慢查询中出现关于information_schema中表时,也可以考虑禁用该参数)

处理依据:

当学校的一个食堂一分钟只能为两个打饭, 忽然来了100个时人来打饭,又没排队, 不出会现了打饭的师傅要用点时间

去选择为那个用户服务了, 人越多,场面就越乱, 难免出现用户大吼该他的场面, 最后有可能就出现不是打饭了,而时之间相互

打架了,打饭的师傅也将收到同时有90个以上的Server too busy. 如果能排一下队.最多也就50分钟能处理完了.

以前办法,应该可以让MySQLD不会挂掉.如果业务支撑受到限制,还是想办法处理一下.

如若满意,请点击右侧【采纳答案】,如若还有问题,请点击【追问】

希望我的回答对您有所帮助,望采纳!

~ O(∩_∩)O~


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

原文地址: http://outofmemory.cn/zaji/8661998.html

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

发表评论

登录后才能评论

评论列表(0条)

保存