大数据mysql 为啥io过高

Posted 2023-03-20

参考技术A 读写频繁，自然io就高了 参考技术B 1、日志产生的性能影响:
由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。mysql的日志包括错误日志（ErrorLog），更新日志（UpdateLog），二进制日志（Binlog），查询日志（QueryLog），慢查询日志（SlowQueryLog）等。当然，更新日志是老版本的MySQL才有的，目前已经被二进制日志替代。
在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中，都至少需要打开二进制日志，因为这是MySQL很多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。有时候为了进一步的性能优化，定位执行较慢的SQL语句，很多系统也会打开慢查询日志来记录执行时间超过特定数值（由我们自行设置）的SQL语句。
一般情况下，在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中，会该系统带来比较大的IO负担，而带来的实际效益却并不是非常大。一般只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做相应的分析。所以，在MySQL系统中，会对性能产生影响的MySQL日志（不包括各存储引擎自己的日志）主要就是Binlog了。

Mysql磁盘IO占用过高的一种解决办法

背景：

在之前的主从同步过程中（Mysql的多级复制），从数据库Z存在磁盘IO占用过高的问题。

磁盘IO在同步期间占用率达到100%，且数据存在滞后，不能实现实时更新。

从数据库的磁盘为机械硬盘，读写性能相对于固态硬盘要差一点。

一、原因：

可能是因为MySQL在日志在每次事务提交时，都会将其写入并刷新到磁盘，造成磁盘IO的高占用。

二、查看配置：

通过在MySQL命令行运行以下命令：

show variables like 'sync_binlog';

可以看到：sync_binlog 的值为1。

该值意味着：启用在提交事务之前将二进制日志同步到磁盘。这是最安全的设置，但是会造成磁盘的较高占用。

show variables like 'innodb_flush_log_at_trx_commit';

可以看到：innodb_flush_log_at_trx_commit 的值为1。

该值意味着：日志会在每次事务提交时写入并刷新到磁盘。

三、配置参数含义：

sync_binlog：控制MySQL服务器将二进制日志同步到磁盘的频率

默认值：1
最小值：0
最大值：4294967295

sync_binlog=0：禁用 MySQL 服务器将二进制日志同步到磁盘。相反，MySQL服务器依赖于操作系统不时将二进制日志刷新到磁盘，就像它对任何其他文件所做的那样。此设置提供最佳性能，但在发生电源故障或操作系统崩溃时，服务器可能已提交尚未同步到二进制日志的事务。

sync_binlog=1：启用在提交事务之前将二进制日志同步到磁盘。这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响。如果发生电源故障或操作系统崩溃，二进制日志中缺少的事务仅处于就绪状态。这允许自动恢复例程回滚事务，从而保证二进制日志中不会丢失任何事务。

sync_binlog=N，其中 N 是 0 或 1 以外的值：收集二进制日志提交组后，二进制日志将同步到磁盘。如果发生电源故障或操作系统崩溃，服务器可能已提交尚未刷新到二进制日志的事务。由于磁盘写入次数增加，此设置可能会对性能产生负面影响。值越高，性能越高，但数据丢失的风险也会增加。

innodb_flush_log_at_trx_commit：控制提交操作的严格 ACID 合规性与重新排列并批量完成与提交相关的 I/O 操作时可能实现的更高性能之间的平衡。

默认值为1

有效值为：0、1、2

可以通过更改默认值来获得更好的性能，但随后可能会在崩溃中丢失事务。

innodb_flush_log_at_trx_commit=1 ：完全符合 ACID 所必需的。日志在每次事务提交时写入并刷新到磁盘。

innodb_flush_log_at_trx_commit=0：每秒将日志写入磁盘并刷新一次。尚未刷新其日志的事务可能会在崩溃中丢失。

innodb_flush_log_at_trx_commit=2：在每次事务提交后写入日志，并每秒刷新一次到磁盘。尚未刷新其日志的事务可能会在崩溃中丢失。

对于设置 0 和 2，不能 100% 保证每秒一次刷新。由于 DDL 更改和其他内部活动导致独立于innodb_flush_log_at_trx_commit设置刷新日志，刷新可能会更频繁地发生，有时由于计划问题而降低刷新频率。如果每秒刷新一次日志，则崩溃时最多可能会丢失一秒钟的事务。如果刷新日志的频率高于或低于每秒一次的频率，则可能丢失的事务量会相应地变化。

四、通过修改配置解决问题：

注意：这种解决办法是在牺牲数据库安全的前提下，提高磁盘的性能！！！更改配置可能会带来更高的数据丢失风险！！！

可以通过以下两条命令修改配置。 

set global sync_binlog=你希望的值;

set global innodb_flush_log_at_trx_commit=你希望的值;

更多设置请参考：

MySQL的二进制日志记录选项和变量