运行 MySQL 8.0 的服务器，swap 分区是否必须关闭？如何设置 vm.swappiness？-云计算导航

直接给结论：运行 MySQL 8.0 的服务器，swap 分区通常建议关闭（或设置为极小值），且必须将 vm.swappiness 调至最低（推荐值为 1）。

这不是什么玄学，而是基于数据库对 I/O 延迟极度敏感的特性。下面拆解其中的逻辑和具体操作方案。

MySQL 的核心瓶颈往往不在 CPU，而在磁盘 I/O。

当物理内存（RAM）耗尽时，如果开启了 Swap，Linux 内核会开始把不常用的内存页交换到磁盘上。对于普通 Web 应用，偶尔的换页可能只是让用户页面慢半秒；但对于 MySQL，一旦触发 Swap，情况就变了：

I/O 延迟爆炸：内存访问速度是纳秒级，而 SSD 是微秒级，机械硬盘更是毫秒级。这种数量级的差异会导致数据库查询瞬间卡顿。
抖动效应（Thrashing）：数据库进程频繁读写数据，导致内存刚被换出去又立刻需要换回来。系统会在“交换”和“读取”之间疯狂震荡，CPU 利用率飙升但实际业务吞吐量归零。
连接数雪崩：MySQL 的每个连接都需要占用一定的内存结构。如果因为 Swap 导致主线程阻塞，新的连接请求排队等待，最终可能导致连接数爆满，服务直接不可用。

在云环境或高负载场景下，Swap 的引入往往是导致 MySQL 性能“断崖式下跌”的隐形杀手。

vm.swappiness 是 Linux 内核的一个参数，范围是 0-100，代表内核倾向于使用 Swap 的激进程度。

默认值：通常是 60。这意味着内核认为只要还有 40% 的物理内存可用，就可能开始考虑用 Swap。这对 MySQL 来说太激进了。
推荐值：1。这告诉内核：“除非物理内存真的彻底没救了（OOM），否则绝对不要用 Swap”。
极端值：0。在某些极度追求稳定性的生产环境中，可以设为 0，强制禁止交换。但在现代 Linux 内核中，0 和 1 的行为差异极小，设为 1 是兼顾安全与性能的通用标准。

# 设置 swappiness 为 1
sudo sysctl vm.swappiness=1

# 查看当前值确认
cat /proc/sys/vm/swappiness

编辑 /etc/sysctl.conf 文件，添加或修改以下行：

vm.swappiness = 1

保存后执行 sysctl -p 使配置立即生效。

这里有两个选择，取决于你的服务器内存总量和预算：

策略 A：彻底关闭 Swap（推荐用于大内存服务器）
如果你的机器内存充足（例如 32GB 以上，且 MySQL 配置的 innodb_buffer_pool_size 合理），直接关闭 Swap 是最稳妥的。

禁用方法：

# 停止 swap
sudo swapoff -a

# 注释掉/etc/fstab 中的 swap 条目，防止开机自动挂载
# 编辑 /etc/fstab，找到包含 'swap' 的行，在前面加 # 注释掉

风险：如果发生内存泄漏或突发流量导致 OOM（Out Of Memory），进程会被直接杀死（Killed）。为了避免这种情况，你需要确保监控到位，或者配置 oom_score_adj 让 MySQL 优先保活。

策略 B：保留少量 Swap 作为“最后一道防线”
如果内存较小（如 8GB 或 16GB），完全关闭 Swap 可能导致在极端峰值下直接崩溃。此时建议保留一个较小的 Swap 分区（如 2GB-4GB），并将 swappiness 设为 1。

逻辑：平时几乎不会用到它。只有当物理内存耗尽到极限时，系统才会启用它来避免进程被直接杀掉，虽然性能会下降，但至少能撑住一段时间让你去排查问题或扩容，而不是直接挂掉。

不要只看 Swappiness：很多运维只改了 swappiness，却忘了调整 MySQL 自身的内存配置。务必确保 innodb_buffer_pool_size 设置为物理内存的 50%-70%（独享数据库服务器时），留出足够空间给操作系统和其他进程。如果 MySQL 占满了内存，再低的 swappiness 也救不了。
监控指标：上线后重点观察 si/so (swap in/out) 指标。如果这两个值长期为 0，说明配置成功。如果突然跳变，说明发生了严重的内存压力。
SSD 寿命：如果你使用的是机械硬盘，Swap 带来的性能衰减是毁灭性的；如果是企业级 SSD，虽然速度快些，但频繁的 Swap 写入也会提速磁盘损耗并占用带宽。

总结：
对于生产环境的 MySQL 8.0，最佳实践是将 vm.swappiness 设为 1。至于是否删除 Swap 分区，遵循“内存充足则删，内存紧张则留小量”的原则。核心目标只有一个：杜绝非必要的磁盘 I/O 干扰数据库的高频内存访问。