MySQL深入——13
今天我们来谈谈饮鸩止渴提高性能的方法
下面说两种情况分别是短连接造成的和慢查询性能问题
短连接
短连接是成本十分高的连接，因为他要进行HTTP的三次握手，确定登陆后的权限判断，在业务高峰期的时候，短连接数会暴增，即为短连接风暴，这会造成cpu资源大多数去处理权限连接处理，在对连接后的业务分配的cpu资源就会减少。
MySQL有一个max_connections参数，是用来控制sql的实际连接数，如果超出了则会报出To many connections的错误
在机器负载比较高的时候，处理现有连接的请求时间变长，每个连接的保持时间变长，如果有新连接，则有可能超出max_connections的限制，碰到上述情况，我们可能会想去提高max_connections的大小，但是这种情况会让CPU资源去用于验证，争取不到CPU资源去执行业务。
那么这种情况我们该怎么办呢？
1.我们可以kill掉连接不工作的线程
可以通过show processlist结果看，踢掉显示为sleep的线程，但是这种情况可能是有损的，假如说A线程执行一个insert任务，但是没有commit，B线程执行一个select查询，我们如果Kill掉这两个线程，B线程是没有影响的，A线程会造成事务回滚，所以优先级是B大于A的。
要去查询事务的具体状态，查information_schame库的innodb_trx表
优先kill掉事务外的空闲connection，不行了再去kill事务内的连接
2. 减少连接过程中的资源消耗
我们可以知道，短连接风暴带来的是CPU资源用于验证连接信息，那么我们可以通过设置来使得系统跳过这个验证的过程直接连接数据库进行操作，通过重启数据库并使用skip_grant_tables参数启动
这是风险极高的操作，容易让数据库被攻击
慢查询性能问题
造成这种情况的可能有三种：
1.索引没有设计好
2.SQL语句没有写好
3.MySQL选错了索引
对于第一种情况我们可以通过紧急创建索引来解决，比较理想的情况是有两个库来使用，一个主库一个备库，大致流程是这样的在备库上执行set sql_log_bin=off，就是不写binlog，然后执行alter table 语句追加上索引，执行主备切换，然后在备库上执行上述的操作，加上索引。
对于第二种情况我们可以通过query_rewrite功能把输入的一种语句改为另外一种模式
对于第三种情况应急方案就是给这个语句加上force index
QPS突增问题
QPS（Queries Per Second）即每秒查询率，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。它也是每秒的响应请求数，也即是最大吞吐能力。QPS主要用来衡量系统性能，特别是在处理大量请求时系统的表现。在因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能。
由于业务突然出现高峰或者应用程序出现bug，导致的语句QPS突增，可能会导致MySQL压力过大，影响服务。
分以下几种情况来处理：
1.是全新的业务bug导致的，如果运营是规范的，如果确定业务方会下掉这个功能，就直接从数据库端把白名单去掉。
2.如果连接到是一个单独连接的数据库用户，可以直接将这个用户删掉，断开连接，由它引发的QPS就会变为0
3.如果新增的功能是和主题功能连接在一起的，我们就只能通过处理语句来限制，将最大是QPS语句改为select 1 返回即可。
这种方法是有很大的风险的，因为如果其他业务也用到了这个板块的sql语句模板，就会有误伤，而且很多业务不是靠一个语句的逻辑完成的，把这个语句设置为select 1就会导致连锁反应导致后面的业务逻辑一起失败