有哪些方法可以改善 MySQL 的 IO 瓶颈问题
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了有哪些方法可以改善 MySQL 的 IO 瓶颈问题相关的知识，希望对你有一定的参考价值。
通过sysbench的oltp_read_write测试来模拟业务压力、以此来给指定的硬件环境配置一份比较合理的mysql配置文件。
环境介绍
硬件配置
请点击输入图片描述
软件环境
请点击输入图片描述
优化层级与指导思想
优化层级
MySQL数据库优化可以在多个不同的层级进行，常见的有：
SQL优化
参数优化
架构优化
本文重点关注：参数优化
指导思想
日志先行 -- 一个事务能否成功提交的关键是日志是否成功落盘，与数据没有太大的关系；也就是说对写的优化可以表述为各方面的资源向写操作倾斜。
瓶颈分析 -- 通过show global status 的各个计数器的值基本上就能分析出当前瓶颈所在，再结合一些简单的系统层面的监控工具如top iostat 就能明确瓶颈。
整体性能是“读”&“写”之间的再平衡。
如果是 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 瓶颈问题的主要内容，如果未能解决你的问题，请参考以下文章