大批量合并insert导致的MySQL性能问题分析

问题反馈

用户反馈insert待入库的队列堆积，当前还有1000W+的insert在消息队列中等待入口，请求堆积严重，怀疑数据库性能有问题

入库队列拥堵值

用户质疑

分析如下两张图中的时间点，那么如果是因为大量合并insert导致的IO瓶颈，那么下午两点的时候，宿主机IO负载降低到正常水平时，通过分析慢查询日志，发现insert指令执行反而更慢，拥塞反而更严重？

错误码、业务量级、入库队列拥堵值

实例维度以及宿主机维度的信息

排查问题

show processlist发现，有大量合并后的批量insert

实例活跃线程

查看云控制台和后台监控信息，可以看到IO已经打满了

实例维度以及宿主机维度的磁盘写入监控图

查看实例详细的数据监控，我们可以看到

实例详细监控数据

解答客户疑惑：

• 为什么只有故障那天异常，客户一直都是如此使用的，之前的时候队列不会如此拥塞？

由于批量合并insert超出了吞吐极限，导致写了磁盘，导致了出现异常，异常原因及原理参考上面截图

-当宿主机IO负载降低到正常水平时，通过分析慢查询日志，发现insert指令执行反而更慢，拥塞反而更严重

上午磁盘IO高的原因是请求在正常执行，写log buffer都是写内存，下午磁盘IO低的原因是写了物理磁盘，导致请求堆积，请求处理变慢，比如之前每秒处理10个请求，当然IO也高，由于SQL执行快因此队列不拥堵，但是一旦log buffer写满了，要写物理盘，那么现在每秒处理1个请求，IO当然会降低，队列肯定会拥堵

解决方案

• insert合并量级调整，从200调整到50（客户已完成）
• 大量insert插入对宿主机磁盘IO性能要求较高，迁移至宿主机IO利用率低的迁移
• 该库还做运营查询，因为写入量太大，容易拥塞，建议读写分离
• 业务层做水平拆分，把对于一个实例的写入请求拆分到多个实例