本文共 959 字，大约阅读时间需要 3 分钟。

场景1：db内存1.5G，业务很少，平时qps不到10，每天凌晨5点到9点内存使用飙升到100%，内存100%时qps有个激增到20，cpu使用率也有激增

解决方法

1 查看缓冲池大小是900M

mysql> show variables like '%innodb_buffer_pool_size%';

+-------------------------+-----------+ | Variable_name           | Value     | +-------------------------+-----------+ | innodb_buffer_pool_size | 943718400 | +-------------------------+-----------+ 1 row in set (0.00 sec)

2 查看缓冲池使用率 show engine innodb  status，查看还剩41226*16/1024=644M

Buffer pool size   57599

Free buffers       41226 Database pages     16326 Old database pages 6040 Modified db pages  13

3 因为周期性的原因，查看当时的定时备份时间，发现开始时间正好是晚上5点，确认是db备份引起的

backup_count: 7

backup_begintime: 5 backup_duration: 24 manual_backup_count: 3

4 因为mysqldump前会有一个flush tables with read lock的操作来记录下当前状态show master status，如果当前有查询，这个操作会等待所有当前查询完成后才执行。内存较少，建议客户升级内存，优化慢查询。

场景2：主库在每天凌晨3点，连接数突然从600激增到1200以上，并堆积许多慢查询，持续几个小时，其他监控参数都比较正常

解决方法

1 查看到当时的慢查询均是些简单SQL，SQL语句本身不存在问题

2 查看到主库备份时间为凌晨3点，确定是定时备份引起的

3 因为正好存在从库，后续将定时备份移到从库解决，mysqldump --dump-slave=2