catalog
- 短连接风暴
- 先处理占着连接但是不工作地线程
- 减少连接过程的消耗
- 慢查询性能问题
- 索引没有设计好
- 语句没写好
- 选错索引
- QPS突增问题
短连接风暴
正常的短连接：
执行很少sql语句就断开，下次需要的时候再重连。MySQL建立连接的过程成本很高，包含：网络连接三次握手、登录权限判断、获得连接的数据读写权限。
短连接模型存在风险：一旦数据库处理得慢一些，连接数就会暴涨。
有两个方法能够有损地解决短链接风暴问题
先处理占着连接但是不工作地线程
如果连接数，可以优先断开事务外空闲太久地连接。如果这样还不够，再考虑断开事务内空闲太久的连接。
当一个客户端处于sleep状态，它的连接被服务端主动断开后，客户端并不会立即知道。而是在客户端发起下一个请求的时候，才会收到报错：
ERROR 2013 (HY000): Lost connection to MySQL server during query
有的应用端收到这个错误时不会重新连接，而是用这个句柄重试查询，这回导致从应用端看MySQL一直没恢复。
减少连接过程的消耗
让数据库跳过权限验证阶段。
方法：重启数据库，并使用-skip-grant-tables参数启动。这样MySQL就会跳过所有的权限验证阶段，包括连接过程和语句执行过程在内。
这个风险极高。在MySQL8.0版本里，如果启用-skip-grant-tables参数，MySQL会默认把--skip-networking参数打开，表示这时候数据库只能被本地客户端连接。
慢查询性能问题
索引没有设计好
通过紧急创建索引来解决。
直接执行alter table语句。
假设现在服务是一主一备，主库A、备库B，这个方案的大致流程是这样的：
1、在备库B上执行set sql_log_bin = off,不写binlog，然后执行alter table，加上索引
2、执行主备切换
3、主库是B，备库是A。在A上执行set sql_log_bin = off，然后执行alter table，加上索引。
语句没写好
在之前的文章中，提到过，有时候一些错误会导致语句没有使用上索引。
此时通过改写sql语句来处理，query_rewrite功能，可以把输入的一种语句改写成另外一种模式。
如果我们一开始写的是：
select * from t where id + 1 = 10000;
可以通过下面代码增加一个语句改写规则。
insert into query_rewrite.rewrite_rules(pattern,replacement,pattern_databas) values ("select * from t where id + 1 = ?","db1");
call query_rewrite.flush_rewrite_rules();
call query_rewrite.flush_rewrite_rules()是让插入的新规则生效。
选错索引
应急方案：给语句加上force index;
QPS突增问题
QPS每秒查询率(Query Per Second) 有时会由于业务高峰或者应用程序bug出现突增。
最好的办法是让业务把这个功能下掉，服务自然就会恢复。
下掉一个功能的方法如下：
1、如果是全新业务的bug，如果去欸的那个业务方会下掉这个功能，那么可以从数据库端直接把白名单去掉
2、如果这个功能使用的是单独的数据库用户，可以用管理员账号把这个用户删掉，然后断开现有连接。
3、如果这个功能和主体功能是部署在一起的，那么我们只能通过处理语句来限制。可以使用查询重写功能，把压力最大的sql语句直接重写为"select 1"返回。
下掉一个功能所带来的副作用如下：
1、如果别的功能里面也用到了这个sql语句模板，会有误伤
2、很多业务并不是靠着一个语句就能完成完整逻辑，所以单独把一个语句以select 1的结果返回的话，可能会导致后面的业务逻辑一起失败。
