有哪些方法可以改善 MySQL 的 IO 瓶颈问题

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了有哪些方法可以改善 MySQL 的 IO 瓶颈问题相关的知识,希望对你有一定的参考价值。

通过sysbench的oltp_read_write测试来模拟业务压力、以此来给指定的硬件环境配置一份比较合理的mysql配置文件。


环境介绍

硬件配置


请点击输入图片描述

软件环境


请点击输入图片描述


优化层级与指导思想

优化层级

MySQL数据库优化可以在多个不同的层级进行,常见的有:

    SQL优化

    参数优化 

    架构优化

    本文重点关注:参数优化

    指导思想

    日志先行 -- 一个事务能否成功提交的关键是日志是否成功落盘,与数据没有太大的关系;也就是说对写的优化可以表述为各方面的资源向写操作倾斜。

    瓶颈分析 -- 通过show global status 的各个计数器的值基本上就能分析出当前瓶颈所在,再结合一些简单的系统层面的监控工具如top iostat 就能明确瓶颈。

    整体性能是“读”&“写”之间的再平衡。

参考技术A 1.IO 对数据库的影响较大 linux 默认的 IO 调度算法为 cfq 需要修改为 deadline
如果是 SSD 或者 PCIe-SSD 设备 需要修改为 noop
2.由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源
所以默认仅仅打开错误日志即可 关闭其他所有日志 以达到减少 IO 损耗的目的

《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) 可以减少需要这类操作的机会。 

以上是关于有哪些方法可以改善 MySQL 的 IO 瓶颈问题的主要内容,如果未能解决你的问题,请参考以下文章

面试官三连问:分库分表了解吧?业界有哪些常用方案?可能存在什么问题?

MySQL 的实时性能监控利器

怎么判断mysql读和写达到了瓶颈

采购实用技巧,5个瓶颈物料的采购方法

有什么方法可以改善构建/编译时间?

MySQL:常用分库分表方案汇总