我正在对使用 MySQL 的应用程序进行压力测试。瓶颈是 MySQL 磁盘（主数据和重做日志分开），它们被写入了相当多的数据。atop表示它们的使用率接近 100%。如果我禁用重做日志（ALTER INSTANCE DISABLE INNODB REDO_LOG），那么磁盘使用率就会变得微不足道（主磁盘为 2%，重做日志磁盘自然为零）。
我需要减少磁盘使用量（不需要微不足道，但必须少得多），而无需禁用重做日志。如果发生崩溃，丢失几秒钟（甚至几分钟）的数据是可以的。我试过这个：
innodb_flush_method = O_DSYNC
innodb_flush_log_at_trx_commit = 0
innodb_flush_log_at_timeout = 5
但我没有发现任何区别。
我还能做什么吗？
这是 Ubuntu 20.04 上的 MySQL 8.0.29。
（注意：该应用程序是 Nextcloud，显然它发出了许多数据库写入请求。）
答案1
我发现这更多的是 Nextcloud 的问题，而不是 MySQL 的问题。
通过检查 的输出Innodb_os_log_written部分SHOW GLOBAL STATUS，我确认它以每秒 1M 或更高的速度向重做日志写入数据。显然，正是数据量大才导致我的磁盘速度慢，而不是数据同步的时间和方式的细节。
通过设置general_log='ON'和检查查询，我最终发现，这是一个Nextcloud 错误，其中登录导致过多查询。在采用截断表的解决方法后oc_authtoken，写入重做日志的速率下降到不到原来的十分之一。