读mysql45讲-解决mysql压力的临时方案

最新推荐文章于 2024-07-12 13:27:28 发布

西埃斯迪恩-霖

最新推荐文章于 2024-07-12 13:27:28 发布

阅读量648

点赞数

分类专栏：待删除

本文链接：https://blog.csdn.net/ZRL1996/article/details/123454930

版权

数据库连接 max_connections 慢查询事务管理性能优化

关键词由CSDN通过智能技术生成

待删除专栏收录该内容

82 篇文章 0 订阅

订阅专栏

短连接风暴

正常的短连接模式就是连接到数据执行很少的sql语句之后断开，下次需要的时候再次重新连接。使用短连接可能会在业务高峰期的时候出现连接数量暴增的情况。
max_connections参数就是用来控制连接的数量，超过这个值，数据库就会拒绝新的连接请求，并报错 too many connections;对于被拒绝连接的请求，从业务上来看就是数据不可用了。
在出现连接不够用的情况，自然会想到将max_connections设置高，但是这么做会有风险，连接变多了，数据库需要耗费资源对每个连接都需要做权限验证，对数据库的压力就会变大，从而会引起已经连接到数据库的请求没有cpu资源去执行sql。

处理掉空闲的连接

max_connections的计算是只要有请求保持连接，就会计算，并不会在意连接是否在工作中。这种情况就可以用kil connection id 给请清除掉。
执行下面的sql：

在这里插入图片描述

然后执行show processlist命令查看当前线程状况：

在这里插入图片描述

id是147889 14890 14891这三个就是刚才执行sql后生成的线程；147889 14890 这两个sql的command那一列都是sleep，但是sessionA是因为事务还未提交，这个时候从业务来看是不能给清除掉的，不然就会回滚处理。但是sessionB是可以清除掉的，并不会有大的影响。所以按照优先级来说应该处理掉sessionB这样事务外空闲的连接。

查询information_schema.innodb_trx表可以直到哪些连接是在事务中的：

在这里插入图片描述

可以看到trx_mysql_thread_id那一列的值是147890，表明这个sql还是事务中，所以用kill connection 147889给清除掉sessionB的线程。然后提交sessionA,表里就多出了插入的数据，说明没有kill错。但是这种主动去断开连接的操作肯定会给业务造成影响。

减少连接的消耗

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

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

慢查询性能问题

在mysql中，引发性能问题的慢查询可能是因为三个原因：

索引没有设计好
sql语句的问题
优化器选错了索引

索引没有设计好的话，可以通过直接alter table语句的方式直接加上索引。

sql语句写的不够好导致查询很慢，可以通过query_rewrite功能将输入的语句改写成另外一种模式：

insert into query_rewrite.rewrite_rules(pattern,replacement,pattern_database) values ("select * from t where id +1 = 1 00","select * from t where id =99","test");

call query_rewrite.flush_rewrite_rules();