mysql大数据量查询瓶颈解决方案-供参考

项目运行了三年了,流水表主表数据已经达到4kw以上

所以最近项目开始时不时的出现问题,主要体现在以下方面:

1.客户端经常出现查询超时。

        1.1 mybatis分页查询出现问题。

        对于这个情况,我在这篇博客中做了描述,可以移步查看下。

        https://mp.csdn.net/mp_blog/creation/editor/134708058

        1.2 项目里面一些统计或者趋势图开始出现问题

        这种情况看到后基本情况就是sql中常出现count()、sum()等等聚合函数。查了一下午资料,发现还是对于mysql没有理解透彻,本来以为聚合函数就是简单的累加等操作,结果发现mysql会一条条的取出来然后进行累计或其他操作。

2.高峰期有时候日志会报锁表。

        这个情况的出现是因为,我最近看到主表数据量太大了,所以就开始分表操作。按月进行分表,主要逻辑是每三分钟从主表中取出最早一小时的数据(大概在3k-5k条),然后插入到月表,然后根据id批量删除主表。

        但是就是这个简单的操作,看似没什么问题,今天高峰期的时候,CPU直接飙升到200%。然后仔细分析后,就是高峰期的时候对数据库的读写频率本就高,再加上我这个批量操作,直接导致锁表。

针对以上情况,开始跟同事讨论解决方案:

1.读写分离很有必要

为了不让数据库频繁读写导致锁表,必须要把读写分离开启。(之前没有打开)。这样才能保证数据同步到月表中。

2.针对分页的问题已经描述了 请移步,地址在上方

3.分库分表

数据量太大,分库的操作是必须要做的。对于count等聚合函数的操作,只能在数据同步完成后,在月份表里面进行统计。

4.一定要对于经常做统计的数据进行报表处理

具体来讲就是。如果我系统中经常有要查询3天内、7天内...这样的情况,那就要做日报表,每天把数据统计好,这样后面直接从日报表中取数据。如果出现当天每小时的查询,那就要进行时段报表的统计,记录每天每小时的统计数据,这样才能保证不是所有的数据都从主表里面进行查询。因为主表的数据只要慢慢累加,总有一天会达到mysql的瓶颈。目前4KW已经事故频发,迫使我们不得不改造项目。

只是一些经验,当然每个人的情况不一样,因为项目在我们主导,所以可操作空间比较大,但是如果是一些已经运行了很久的项目,最好的方式就是根据上方第四条做拓展,这样不会对原有业务影响太大。

你可能感兴趣的:(sql,mysql,数据库)