《Mysql - 在Mysql服务出现瓶颈时，有哪些“饮鸩止渴”提高性能的方法？》

一：情景

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

　　- 在业务高发时候，Mysql 服务压力过大，导致业务受损， 用户的开发负责人说，不管你用什么方案，让业务先跑起来再说。

　　- 今天我们就来聊聊这些临时方案，并着重说一说它们可能存在的风险。（有损方案，无损方案肯定不会再这个时候才执行）

 

二：短连接导致的性能问题

　　- 为什么短连接会引起数据库的性能问题？

　　　　- 正常的短连接模式就是连接到数据库后，执行很少的 SQL 语句就断开，下次需要的时候再重连。

　　　　- 在 《一条SQL是如何执行的？》 中曾经提到，MySQL 建立连接（需要 TCP 握手，登录权限/数据读写权限 判断）（成本昂贵）。

　　　　- 在数据库压力比较小的时候，这些额外的成本并不明显。

　　　　- 但是，短连接模型存在一个风险，就是一旦数据库处理得慢一些，连接数就会暴涨。（存在于压力大的情况下）

　　　　　　- Mysql 的 max_connections 参数，用来控制一个 MySQL 实例同时存在的连接数的上限。

　　　　　　- 超过这个值，系统就会拒绝接下来的连接请求，并报错提示“Too many connections”。

　　　　　　- 对于被拒绝连接的请求来说，从业务角度看就是数据库不可用。

　　　　- 所以，在机器负载比较高的时候，处理现有请求的时间变长，每个连接保持的时间也更长。

　　　　- 这时，再有新建连接的话，就可能会超过 max_connections 的限制。

 

　　- 为什么不能单纯的通过调高 max_connections 的方式解决短连接过多的问题？

　　　　- 因为设计 max_connections 这个参数的目的是想保护 MySQL.

　　　　- 如果我们把它改得太大，让更多的连接都可以进来，那么系统的负载可能会进一步加大，大量的资源耗费在权限验证等逻辑上.

　　　　- 结果可能是适得其反，已经连接的线程拿不到 CPU 资源去执行业务的 SQL 请求。 

 

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

　　　　- 选择哪些链接断开？

　　　　　　- Show Processlist 为 sleep 的链接。

　　　　　　- 你可以优先断开事务外空闲太久的连接（事务表information_schema.INNODB_TRX）；

　　　　　　- 如果这样还不够，再考虑断开事务内空闲太久的连接。 

 

　　　　- 如何断开短连接？

　　　　　　- 从服务端断开连接使用的是 kill connection + id 的命令。

　　　　　　- 一个客户端处于 sleep 状态时，它的连接被服务端主动断开后，这个客户端并不会马上知道。

　　　　　　- 直到客户端在发起下一个请求的时候，才会收到这样的报错“ERROR 2013 (HY000): Lost connection to MySQL server during query”。 

　　　　

　　　　- 可能存在的问题？

　　　　　　- 从数据库端主动断开连接可能是有损的，尤其是有的应用端收到这个错误后，不重新连接，而是直接用这个已经不能用的句柄重试查询。

　　　　　　- 这会导致从应用端看上去，“MySQL 一直没恢复”。 

 

　　-  第二种方法：减少连接过程的消耗。（取消权限和认证）

　　　　- 有的业务代码会在短时间内先大量申请数据库连接做备用，如果现在数据库确认是被连接行为打挂了，那么一种可能的做法，是让数据库跳过权限验证阶段。

　　　　- 跳过权限验证的方法是：重启数据库，并使用–skip-grant-tables 参数启动。这样，整个 MySQL 会跳过所有的权限验证阶段，包括连接过程和语句执行过程在内。

            - 但是，这种方法特别符合我们标题里说的“饮鸩止渴”，风险极高，特别不建议使用的方案。尤其你的库外网可访问的话，就更不能这么做了。 

 

三：慢查询导致的性能问题

　　- 索引没有设计好

　　　　- 这种场景一般就是通过紧急创建索引来解决。

　　　　- MySQL 5.6 版本以后，创建索引都支持 Online DDL 了。

　　　　- 对于那种高峰期数据库已经被这个语句打挂了的情况，最高效的做法就是直接执行 alter table 语句。

　　　　- 比较理想的是能够在备库先执行。

　　　　- 假设你现在的服务是一主一备，主库 A、备库 B，这个方案的大致流程是这样的：

　　　　　　- 在备库 B 上执行 set sql_log_bin=off，也就是不写 binlog，然后执行 alter table 语句加上索引；

　　　　　　- 执行主备切换；

　　　　　　- 这时候主库是 B，备库是 A。在 A 上执行 set sql_log_bin=off，然后执行 alter table 语句加上索引。

 

　　-  SQL 语句没写好。

　　　　- 慢查询修复。

 

　　-  MySQL 选错了索引。

　　　　- 这时候，应急方案就是给这个语句加上 force index。

 

四：其余的方法

　　- 白名单机制

　　- 业务账号分离。

 

五：小结

　　- 在实际开发中，我们也要尽量避免一些低效的方法，比如避免大量地使用短连接。

　　- 同时，如果你做业务开发的话，要知道，连接异常断开是常有的事，你的代码里要有正确地重连并重试的机制。

　　- DBA 虽然可以通过语句重写来暂时处理问题，但是这本身是一个风险高的操作，做好 SQL (explain) 可以减少需要这类操作的机会。