【问题】
最近有台服务器比较频繁的CPU报警，表现的特征有CPU sys占比偏高，大量慢查询，大量并发线程堆积。后面开发对insert的相关业务限流后，服务器性能恢复正常。
【异常期间线程处理情况】
下图是当时生产环境异常时抓取的信息，该事务正在执行insert，已经执行5秒，线程运行在innodb内核，状态是thread declared inside InnoDB，还有4906 tickets可用
统计了下有64个线程在innodb层，同时看到还有280个线程在排队等待进入innodb线程，状态是sleeping before entering InnoDB
innodb层的并发线程执行的SQL比较慢，产生了阻塞，导致了MySQL的并发线程堆积。
【哪些SQL执行慢】
从正在执行的SQL中，看到了insert的慢查询SQL语句，统计了下这句SQL批量插入大于342条记录(SQL被截断)
【批量insert的性能测试】
类似这种批量的insert SQL会对MySQL性能造成影响吗，多大的批次比较合理呢，做了下面测试
在测试服务器上新建测试表（表结构同生产环境），并定义了5个插入脚本，分别为单条insert，每10条1个批次insert，每50条1个批次insert，每100条1个批次insert，每340条1个批次insert
用压测工具模拟512个并发线程的情况下，不同类型的SQL插入100W条记录服务器的性能情况，下表是压测统计
数据量 | 并发线程 | 执行时间（秒） | 每秒insert | 慢查询数量 | Context switch | CPU使用率 | CPU sys占比 | |
|---|---|---|---|---|---|---|---|---|
普通insert（1条） | 1000000 | 512 | 33 | 3W | 0 | 79W | 73% | 39% |
批量SQL（10条） | 1000000 | 512 | 23 | 4.3W | 0 | 49W | 78% | 56% |
批量SQL（50条） | 1000000 | 512 | 21 | 4.7W | 0 | 42W | 80% | 60% |
批量SQL（100条） | 1000000 | 512 | 15 | 6.6W | 20 | 53W | 70% | 45% |
批量SQL（340条） | 1000000 | 512 | 15 | 6.6W | 200 | 38W | 86% | 70% |
下图是批量SQL（340条）执行时的性能情况，可以看到当每100条记录一个批次执行insert时，开始出现慢查询，每340条1个批次执行insert时，在高并发的情况下，会产生大量的慢查询，这个现象接近于我们目前生产环境异常时的情况
【优化方案】
对于MySQL需要插入大量数据时，每次单条的insert性能较差，为了提升insert性能，我们采用了每批次多条记录同时insert的方法。
但当批次增大到一定数量时，在高并发访问的情况下，单个批次执行的性能会出现较大的下降，出现大量慢查询，并发线程堆积，CPU上升出现瓶颈， innodb层的并发线程处理被慢查询阻塞，后面只能通过限流来缓解性能问题。
根据上面的测试结论，建议控制热表单个批次insert的记录条数，最好单个批次控制在10条左右（因为即使调大到50条，插入性能没有大的提升，在高并发场景下，首先要保证当前SQL的执行性能）。
【优化后CPU告警消失，运行平稳】
