故障表现

他的执行时间超过规定的限制（比如1000ms）

CPU使用率高

大量业务失败，数据连接异常

执行sql越来越慢，失败越来越多

解决方案

定位 + 应急 + 故障恢复

定位

查询慢sql的日志

查看mysql 的performance schena（里面有锁和各种状态）和show processList

是否请求出现请求积压，是否数据库执行时间是否快速增加，出现超时

获取故障日志，查看异常的原因（是too many connection，还是超时）

查看连接池申请的连接数据量，并且定时查看。看是否连接数暴增，是否有连接数泄露的问题。还有是否有服务异常的使用了过多的连接数。

假如有缓存的话，是否出现缓存穿透、缓存雪崩等故障

如果存在主从多个节点的话，定位是否是单个节点出现故障/性能问题而导致异常，是否有某个节点登录不上

查看对应服务的日志量是否大量增加，请求的qps是否爆发性增长（由于用户压测、节假日高峰期、活动导致的qps瞬间增加）

是否有运维故意的写错sql、删库或者其他行为，导致数据库本身出现问题

是否有节点状态异常、重启、切换等（mysql添加心跳检测）。当节点挂的多的情况下，可能会导致其他节点受到太多的业务压力，从而导致节点异常连环崩溃

应急：

show processlist，持续的杀掉慢查询的语句

对慢查询的sql进行溯源，定位调用方IP，然后直接封禁掉对应IP的地址

查询数据库节点对应的cpu占用 + 内存占用 + 磁盘占用

对数据库进行切流

扩容数据库副本数（这个没做过）

故障恢复

是否对高峰期的sql进行限流（需要改动代码）、熔断、降级

在可能的高峰期估算可能的qps，并申请设备、留足余量

优化sql + 索引，替换慢查询的语法

对数据进行反范式编程，允许一定的冗余以适应查询时间

对过期数据进行清理，或者将历史数据更换到其他数据库

备份binlog日志，然后对binlog进行解析，看sql占用时间

添加普罗米修斯等监控，保证数据库的成功率

对核心数据丢失进行人工补救