一些在极端情况下,为了提高连接能力,而使用一些非正常手段

1.短连接地狱

正常的连接是非常耗费资源的,但是在一些极端情况下,可能会出现大量的连接连接上去后立刻断开了

这种时候,所消耗的成本就很高了

可以设置max_connections来避免有过多的连接,但是不能无脑直接设置max_connection这个值,因为可能会出现占用过多的资源

可以使用的方法有

(1).可以杀死哪些空闲的线程,可以就是通过设置wait_timeout来避免在等待一定时间后,直接剔除连接

但是哈,

图片

可能出现如上的误杀情况

2.来减少连接所使用的的消耗

如果连接数量确定非常的大的话,那么可以直接让数据库跳过权限验证阶段,在重新启动数据库的阶段,使用-skip-grant-tables参数来启动,直接跳过所有的权限验证的阶段

但是这是极为不安全的,在MySql 8.0版本后,启用了-skip-grant-tables,会把–skip-networking参数打开,只允许本地客户端连接

3.慢查询性能的问题

引发慢查询的常见情况为

1.没有设计好索引

2.SQL语句没有写好

3.MySQl选错了索引

如果没有设计好索引的话,那么建议直接alter table

流程为可以在备库B上执行set sql_log_bin=off,然后执行alter table语句加上索引

执行主备切换

主库为B,备库为A 在A上执行set sql_log_bin=off,然后alter table语句加上索引

Sql语句没有写好的话

可以通过改写Sql语句来处理,可以通过自动改写功能

query_rewrite功能,如果语句被写成了select * from t where id+1 = 10000;

可以让其自动改写

mysql> insert into query_rewrite.rewrite_rules(pattern, replacement, pattern_database) values (“select * from t where id + 1 = ?”, “select * from t where id = ? – 1”, “db1”);

如果选错了索引,可以使用force index来强制加索引,这个问题,可以在上限之前,通过慢查询日志来进行判断,然后根据explain来查看是否和与其一致

3.QPS突增的问题

如果因为业务暴涨,或者bug问题,会导致某个语句的QPS突增,从而影响服务

但是出现的情况可能会不一致

1.如果是因为全新的业务的bug出现的,直接将这个业务从白名单去掉即可

2,如果是单独的数据库账号,那么可以直接将这个用户删掉,然后断开现有连接,就可以了

3,如果是新增的功能和主体具有耦合性的,那么只能通过限定处理语句来限制,那么可以使用查询重写功能,让其直接重写为select 1返回

但是这必然会导致其他的模块出现业务上的错误

这就需要严格的数据库运维能力

同样需要避免一些低级的错误

发表评论

邮箱地址不会被公开。 必填项已用*标注