短连接风暴

正常的短连接模式就是连接到数据库后，执行很少的SQL语句就断开，下次需要的时候再重连。
如果使用的是短连接，在业务高峰期的时候，就可能出现连接数突然暴涨的情况。

解决方法：（有损）

  1. 处理掉占用连接却不工作的线程，设置wait_timeout参数表示的是，一个线程空闲wait_timeout这么多秒之后，就会被MySQL直接断开连接。如果是连接数过多，你可以优先断开事务外空闲太久的连接；如果这样还不够，再考虑断开事务内空闲太久的连接。注意服务端主动断开连接，客户端并不会马上知道，直到客户端下一次发送请求，所以要及时通知客户端
  2. 减少连接过程的消耗——让数据库跳过权限验证阶段。

慢查询

在MySQL中，会引发性能问题的慢查询，大体有以下三种可能：

  1. 索引没有设计好；
  2. SQL语句没写好；
  3. MySQL选错了索引。

1.索引设计问题
可以创建online DDL,直接执行alter table，比较理想的是能够在备库先执行。假设你现在的服务是一主一备，主库A、备库B，这个方案的
大致流程是这样的：

  1. 让备库B不再写bin_log，执行alter table加上索引。
  2. 执行主备切换
  3. 这时B变成主库，A是备库，在A上同样关闭bin_log，执行alter table加上索引

2.语句没写好
可能的情况：

  1. 对索引字段做了函数计算，导致用不上索引。对索引字段做函数操作，可能会破坏索引值的有序性，因此优化器就决定放弃走树搜索功能。
  2. 隐式类型转换，比如id的类型从string到int。在MySQL中，字符串和数字做比较的话，是MySQ将字符串转换成数字。而对优化器来说，这个转换是调用了函数，同上，对索引字段做了函数操作，优化器放弃走树索引。
  3. 隐式字符编码转换。两张表字符集，一个是utf8，一个是utf8mb4，做表连接查询的时候用不上关联字段的索引。当这两个类型的字符串在做比较的时候，MySQL内部的操作是，先把utf8字符串转成utf8mb4字符集，再做比较。

解决方法：
改写SQL语句来处理。MySQL 5.7提供了查询重写query_rewrite功能，可以把输入的一种语句改写成另外一种模式。添加一些模式，把一些容易误写的模式改成正确的。call query_rewrite.flush_rewrite_rules()这个存储过程，是让插入的新规则生效，也就是我们说的“查询重写”。你

3.MySQL选错索引
没有使用强制索引force index，可能导致MySQL用错索引。

优化器的逻辑首先是扫描行数多少，而后结合是否用临时表，是否需要排序等因素综合判断。最主要的问题在于无法准确判断预计扫描行数

解决方法：使用查询重写功能，给原有语句加上force index

QPS激增

如果是上了一个新功能的bug引起，最理想的情况，我们要用最小的代价停掉这个功能。
如果DB运维比较规范，白名单是逐个添加的，此时如果业务方确定会下掉这个功能，可以从数据库端先把其从白名单踢出去。
如果新功能使用的是单独数据库的用户，可以把这个用户删掉，然后断开现有连接。