MySQL 8.0 引入 innodb_flush_method 等新参数的系统调用分析

本文我们将讨论如何在操作系统级别验证 innodb_flush_method 和 innodb_use_fdatasync 修改为默认值之外的其它值（特别是 O_DIRECT 是最常用的）后的效果。

介绍

首先，让我们定义该 innodb_flush_method 参数的作用。它规定了 InnoDB 如何管理数据刷新到磁盘的行为。文章不会详细说明每个有效值的作用，更多详细介绍请查看参数值文档。

有效值如下（仅限 Unix）：

• fsync
• O_DSYNC
• littlesync
• nosync
• O_DIRECT
• O_DIRECT_NO_FSYNC

如前所述，我们将重点关注 O_DIRECT。作为最佳实践的一部分，我们建议选择 O_DIRECT 避免双缓冲，绕过操作系统缓存，从而提高写入数据时的性能。下面是从官方文档中摘录的 InnoDB 架构：

在支持 fdatasync() 的平台上执行系统调用（System calls，以下简称 Syscalls），MySQL 8.0.26 中引入的 innodb_use_fdatasync 变量允许使用 innodb_flush_method 选项来替代。除非后续数据检索需要，否则系统调用不会刷新对文件元数据的更改，从而提供潜在的性能优势。

要操作文件，MySQL 和任何其他软件都必须调用 Syscalls。每当进程需要系统资源时，它都会通过 Syscalls 向内核发送对该资源的请求。从较高层次来看，系统调用是内核向用户应用程序提供的“服务”。它们类似于库 API，被描述为具有名称、参数和返回值的函数调用。下图是此过程的高级说明：

问题：为什么不直接访问我们想要的资源（内存、磁盘等）？

这是因为 Linux 将进程的执行分为两个空间。用户运行的进程（一般称为用户空间进程）依赖于内核提供的服务。内核是操作系统的一个特定部分，它以特权运行模式处理各种低级操作。这里详细描述了用户空间和内核空间的概念。如果应用程序可以直接读写内核的地址空间，系统的安全性和稳定性就会受到影响。在给定的场景中，一个进程能够访问另一进程的内存区域。这表明内存隔离存在潜在问题，并可能导致安全漏洞。

问题：如何检查我的操作系统是否支持特定的 Syscalls？

$ man syscalls

它将列出可