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

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

环境介绍

硬件配置

请点击输入图片描述

软件环境

请点击输入图片描述

优化层级与指导思想

优化层级

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

SQL优化

参数优化

架构优化

本文重点关注：参数优化

指导思想

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

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

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

首先介绍下 pt-stalk，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。

pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息，这其中包括：

1. OS 层面的 CPU、IO、内存、磁盘、网络等信息；

2. MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。

而且 pt-stalk 是一个 Shell脚本，对于我这种看不懂 perl 的人来说比较友好，脚本里面的监控逻辑与监控命令也可以拿来参考，用于构建自己的监控体系。

三、使用

接着我们来看下如何使用这个工具。

pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件，当触发条件时收集相关诊断数据。

触发条件相关的参数有以下几个：

function：

∘ 默认为 status，代表监控 SHOW GLOBAL STATUS 的输出；

∘ 也可以设置为 processlist，代表监控 show processlist 的输出；

variable：

∘ 默认为 Threads_running，代表 监控参数，根据上述监控输出指定具体的监控项；

threshold：

∘ 默认为 25，代表 监控阈值，监控参数超过阈值，则满足触发条件；

∘ 监控参数的值非数字时，需要配合 match 参数一起使用，如 processlist 的 state 列；

cycles：

∘ 默认为 5，表示连续观察到五次满足触发条件时，才触发收集；

连接参数：host、password、port、socket。

其他一些重要参数：

iterations：该参数指定 pt-stalk 在触发收集几次后退出，默认会一直运行。

run-time：触发收集后，该参数指定收集多长时间的数据，默认 30 秒。

sleep：该参数指定在触发收集后，sleep 多久后继续监控，默认 300 秒。

interval：指定状态参数的检查频率，判断是否需要触发收集，默认 1 秒。

dest：监控数据存放路径，默认为 /var/lib/pt-stalk。

retention-time ：监控数据保留时长，默认 30 天。

daemonize：以后台服务运行，默认不开启。

log：后台运行日志，默认为 /var/log/pt-stalk.log。

collect：触发发生时收集诊断数据，默认开启。

∘ collect-gdb：收集 GDB 堆栈跟踪，需要 gdb 工具。

∘ collect-strace：收集跟踪数据，需要 strace 工具。

∘ collect-tcpdump：收集 tcpdump 数据，需要 tcpdump 工具。

IO过高是指输入输出过高了这个有许多原因都会导致mysqlIO过高了，小编见过apache处理数据缓存导致mysqlIO过高问题当然也有其它关于mysql本身问题导致mysqlIO过高的问题了，下面给各位整理总结一下关于mysqlIO过高处理办法。

<script>ec(2)</script>

1、日志产生的性能影响:

由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。MySQL的日志包括错误日志（ErrorLog），更新日志（UpdateLog），二进制日志（Binlog），查询日志（QueryLog），慢查询日志（SlowQueryLog）等。当然，更新日志是老版本的MySQL才有的，目前已经被二进制日志替代。

在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中，都至少需要打开二进制日志，因为这是MySQL很多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。有时候为了进一步的性能优化，定位执行较慢的SQL语句，很多系统也会打开慢查询日志来记录执行时间超过特定数值（由我们自行设置）的SQL语句。

一般情况下，在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中，会该系统带来比较大的IO负担，而带来的实际效益却并不是非常大。一般只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做相应的分析。所以，在MySQL系统中，会对性能产生影响的MySQL日志（不包括各存储引擎自己的日志）主要就是Binlog了。

2、mysql内执行如下指令：

set global sync_binlog=500

当每进行500次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

set global innodb_flush_log_at_trx_commit=2

默认值1代表每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Battery backed up cache）时。设置为2代表不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值设置为2只会在整个 *** 作系统宕机时才可能丢数据。

注：重新开机后，该指令失效。可在服务启动时，设置如上两项。

---