前言

在高并发下，大量的服务调用中，需要经常对数据库频繁的做操作，但是此时也会带来cpu飙高的问题，所以对mysql的合理操作就显得尤为重要，那么在高并发下如何减少对MySQL集群的压力呢？听我慢慢娓娓道来。

一、是否有高并发流量？

首先需要对服务有很深的了解，才知道哪些模块会涉及到高并发场景，我们可以通过观察服务监控查看最近一个星期或者一个月的服务状态，一般互联网公司都会通过grafana平台直接进行查看（数据写入influxdb，然后集成grafana，做到可视化），可以看到服务的一些cpu状态、jvm内存等信息。

（1）我们可以选择服务压力比较大的时间段，可以看到CPU在这段时间最高飙到85%-90%，可以判定这段时间肯定有大量数据进来：

（2）这段时间的内存，大概50%左右，还好

（3）接着看mysql集群监控，可以先看看master库的实例，因为master库主要是写数据，如果这段时间有大量流量进来，mysql这边肯定也有一部分压力，我们看了之后，果然，CPU压力峰值在62%左右。

综合以上，我们可以确定这段时间服务肯定涌入了大量流量，接着我们可以看看这段时间调用的接口涉及到的mysql的相关操作，看看可以优化的地方。

二、慢SQL优化

1.排查慢SQL

如果mysql集群用的是腾讯云的，可以去公司的运维那申请一个腾讯云账号，看自己服务的mysql集群实例情况。如果是阿里云的，可以去阿里云的平台看，一般它们都提供很丰富的实例监控运行情况相关的界面。

图中就是腾讯云的mysql实例运行情况，我们可以看到图中划红线的地方：

点击一键诊断可以看到具体的慢SQL情况：

从以上图中我们可以看出，当有大流量进来的时候慢SQL的次数其实是很多的，有的服务慢SQL设置为1s，有的为2s，一般都不会超过5s，具体的慢SQL时间视业务场景而定。

• 以上图中可以看到1的地方: SQL耗时1-5s占比3.63%，说明慢SQL还是挺多的；
• 接着看2的地方: 这段SQL的平均执行时间为4.61s，时间明显偏长；
• 继续看3这个地方：平均扫描行数为727w多行，怪不得很慢，原来是SQL扫描的数据量很大导致的。

2.导致慢SQL的原因

我们可以看到以上耗时比较大的几个SQL，其中一个如下：

我们可以看到，这就是一个普通的SQL，但是如果在高并发下，有大流量突然涌进来，这个SQL是不是有问题呢，我们可以看到对应的优化建议，提示建一个组合索引。
然后我看了下原来的表结构，发现确实是缺少相应的索引，原因是什么呢？
分析：因为之前这个表结构上线的时候，没有考虑未来有很大的流量进来，如果QPS不是很高的话，原来这样的SQL是没有问题的，但是一旦大流量打过来，突然很多数据过来，你再去查询，就会出现问题了。

3.解决方案

既然发现了问题，那么应该怎么解决呢。

• 加索引

加索引肯定是能解决的，但是索引也是需要占用内存的，也是有索引空间的，不合适的索引空间可能跟数据空间一样大，这样会占用内存，一个表不建议有太多的索引，一般不超过5个，所以虽然加索引能够解决问题，但是也会带来内存的开销。

• 改变查询方式

如果符合条件的数据很多，我们可以尝试改变这种查询方式，我们可以基于主键id锁定数据范围去查询数据，然后再把查询的数据聚合在一起，这样的话有点像分而治之，查询的rows就不会太大。比如以上SQL，不是有个limit语句吗，可以改成以下：

select * from table where id > value1 and id < value2 and is_delete = ?and status = ? limit ？；

其中id的扫描区间，可以id > value1中的value1值放在redis缓存里，然后每次扫描的时候基于这个id去拉取数据，其中id < value2中的value2的值可以设置为value1+ limit的值,这样的话每次正好扫描limit条数据，如果扫描的数据需要实时动态调整的话，可以将此值放到Apollo配置中，这样每次扫描的rows可以达到动态的配置。

• 大量数据的表是否分库分表

如果一个月的数据达到千万级甚至亿级以上的话，那么就需要考虑分库分表了，减少单表的数据量，从而减少查询的压力，不过具体怎么划分得看业务场景来定。分表的话一般基于某个唯一id进行hash取余或者按月分表，分库的话一般有垂直划分和水平划分两种方式，不过具体的就需要结合业务场景了。

• 不直接查库，能否放入redis缓存

比起直接操作数据库，操作redis集群的压力肯定是要小很多的，如果业务场景支持的话，可以考虑走redis，降低DB的压力。

• 主写、从读、统计库数据分析

一般主库用来写数据，所以主库的性能比较高，从库的话一般用来读数据，相对来说服务压力没有那么大，而且频繁的读也可以结合redis和es来使用，统计库的话用做数据分析，对数据进行分析然后制定相应的策略。一般业务使用的时候，用到mysql的时候需要做到各司其职，否则大流量过来，瞬时的压力是非常大的，很容易造成服务不可用。所以合理的使用各个数据库实例也是很重要的。

总结

其实还有诸多其他的慢SQL情况，排查慢SQL需要结合当时的业务场景，再通过查看相关的监控数据，其实很多东西就能够一目了然，经过对比分析，很快就能找到相应的解决方案，但是解决的时候，还是要以稳定性为主，保证对其他服务无影响，尽量做到无感知。如何更好的使用mysql，就需要对自己的业务有足够的了解，如果有高并发的场景，需要压测评估相关服务的性能压力，然后逐渐去优化，争取把服务做到高可用、高稳定性，并且可扩展，而且还需要相应的监控报警，便于及时知悉服务的相关情况。以上就是作者实战的一些经历，希望以上内容能够对你有所帮助！！！