mysql卡顿但cpu低时，90%概率是vm.swappiness=60导致；应立即执行sysctl vm.swappiness检查，若为60或更高则属高危，须调至1–10并执行sysctl -p永久生效，同时验证si/so是否归零。
vm.swappiness=60 就是 MySQL 卡顿但 CPU 很低的元凶，不是“可能”，而是大概率事实。
怎么看当前 vm.swappiness 是否危险
直接运行 sysctl vm.swappiness。输出值如果是 60（Linux 默认值）或更高，就已触发高风险模式——内核会在物理内存使用率刚过 40% 时，就开始把 InnoDB Buffer Pool 这类匿名页往 Swap 里扔。即使 free -h 显示 SwapUsed 为 0，只要这个值是 60，换页随时可能发生。
- 安全范围是
1～10；1最激进（仅 OOM 前最后一刻才考虑 Swap），10更稳妥 -
vm.swappiness=0不等于禁用 Swap：它只是让内核“只在即将 OOM 时才 Swap”，而 Swap 设备本身仍挂载着，swpd非零、si/so突增仍会发生 - 云主机要额外检查：
swapon --show必须为空；Ubuntu 20.04+ 默认带/swap.img，光改 sysctl 没用
怎么临时调低并立刻验证效果
线上不能等重启，用 sysctl 直接压到最低试探：
sudo sysctl vm.swappiness=1
执行后立刻用 vmstat 1 观察 si（swap-in）和 so（swap-out）两列：
- 如果之前持续 >1000 KB/s，现在掉到 0 或个位数，基本锁定 Swap 是瓶颈
- 别用
echo 1 > /proc/sys/vm/swappiness：它不校验取值，输错（比如写成 1000）内核会静默失败 - 调完立刻
watch -n1 'cat /proc/sys/vm/swappiness'盯几秒，防某些运维脚本自动回滚 - 容器环境注意：
docker run没加--memory-swappiness=1，宿主机设置对容器内 MySQL 无效
怎么永久生效且不被覆盖
编辑 /etc/sysctl.conf，末尾追加一行：
vm.swappiness=1
然后必须执行：
sudo sysctl -p
漏掉这步，等于白改——很多团队改完文件忘了 -p，重启后发现还是 60。
- 不要往
/etc/sysctl.d/下乱建 conf 文件：部分发行版加载顺序不保证，sysctl -p可能不读 - 验证是否生效：
sysctl vm.swappiness输出必须是1，且cat /etc/sysctl.conf | grep swappiness能捞出那行 - CentOS/RHEL 7+ 环境慎设为 0：新内核下可能引发 OOM，
1是更安全的生产选择
真正容易被忽略的是：调完 vm.swappiness 后，还得确认 MySQL 进程没被 NUMA 绑定策略反向拖垮——比如 numactl --membind=0 强制绑单节点，结果其他节点空闲内存宁可 Swap 也不给用。这不是参数问题，是资源调度逻辑冲突。
