业务高峰期，生产环境的 MySQL 压力太大，没法正常响应，需要短期内、临时性地提升一些性能，可用的方法有哪些？

1. 第一种方法：先处理掉那些占着连接但是不工作的线程。

2. 第二种方法：尽量减少短链接消耗，一种可能的做法，是让数据库跳过权限验证阶段：解决办法：跳过权限验证的方法是：重启数据库，并使用–skip-grant-tables 参数启动。这样，整个 MySQL 会跳过所有的权限验证阶段，包括连接过程和语句执行过程在内。风险极高，是我特别不建议使用的方案。尤其你的库外网可访问的话，就更不能这么做了。在 MySQL 8.0 版本里，如果你启用–skip-grant-tables 参数，MySQL 会默认把 --skip-networking 参数打开，表示这时候数据库只能被本地的客户端连接。可见，MySQL 官方对 skip-grant-tables 这个参数的安全问题也很重视。

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

   • 索引没有设计好；SQL 语句没写好；
   • MySQL 选错了索引。

   预防办法： 通过下面这个过程，我们就可以预先发现问题。上线前，在测试环境，把慢查询日志（slow log）打开，并且把 long_query_time 设置成 0，确保每个语句都会被记录入慢查询日志；在测试表里插入模拟线上的数据，做一遍回归测试；观察慢查询日志里每类语句的输出，特别留意 Rows_examined 字段是否与预期一致。

4. QPS 突增问题有时候由于业务突然出现高峰，或者应用程序 bug，导致某个语句的 QPS 突然暴涨，也可能导致 MySQL 压力过大，影响服务。 如果从数据库端处理的话，对应于不同的背景，有不同的方法可用。

   • 一种是由全新业务的 bug 导致的。假设你的 DB 运维是比较规范的，也就是说白名单是一个个加的。这种情况下，如果你能够确定业务方会下掉这个功能，只是时间上没那么快，那么就可以从数据库端直接把白名单去掉。
   • 如果这个新功能使用的是单独的数据库用户，可以用管理员账号把这个用户删掉，然后断开现有连接。这样，这个新功能的连接不成功，由它引发的 QPS 就会变成 0。
   • 如果这个新增的功能跟主体功能是部署在一起的，那么我们只能通过处理语句来限制。这时，我们可以使用上面提到的查询重写功能，把压力最大的 SQL 语句直接重写成"select 1"返回。

   当然，这个操作的风险很高，需要你特别细致。它可能存在两个副作用：

   • 如果别的功能里面也用到了这个 SQL 语句模板，会有误伤；
   • 很多业务并不是靠这一个语句就能完成逻辑的，所以如果单独把这一个语句以 select 1 的结果返回的话，可能会导致后面的业务逻辑一起失败。

   方案 1 和 2 都要依赖于规范的运维体系：虚拟化、白名单机制、业务账号分离。由此可见，更多的准备，往往意味着更稳定的系统。