一眼确认swap抖动需运行vmstat 1，若swpd>0且si/so持续>1000kb/s即锁定问题；swappiness=0不能禁用swap，内存耗尽时仍会换页；o_direct须配swappiness=1、memlock unlimited及strace验证才有效。
MySQL性能剧烈波动但CPU很低，基本就是Swap在换页——不是SQL慢、不是锁冲突，是内存页正被反复踢出又拉回磁盘。临时调vm.swappiness=1能压住si/so，但不配memlock和验证，抖动还会回来。
怎么一眼确认是Swap在抖？
别看top里mysqld的%Cpu，也别急着查慢日志。直接跑：vmstat 1，盯住si（swap-in）和so（swap-out）两列：
- 单位是KB/s，只要任一值稳定 >1000，就已严重异常
-
swpd > 0+si/so > 0同时成立，基本可锁定Swap问题 -
free -h里SwapUsed上涨只是结果，vmstat才是过程证据 - 注意：
used内存高不危险，MemAvailable持续低于1G才真危险
为什么vm.swappiness=0还是抖？
设成vm.swappiness=0只是告诉内核“尽量不用Swap”，不是禁用。当Buffer Pool配得过大、其他进程吃光剩余内存，物理内存真的耗尽时，内核仍会触发si/so，查询线程卡在缺页中断里，表现为毫秒级延迟突增。
- 这不是配置没生效，是内存压力已穿透策略边界
- 生产环境更稳妥的做法是设为
1：既压制换页冲动，又给OOM前留一点缓冲余地 - 云主机（如Ubuntu 20.04+）还要确认
swapon --show输出为空，否则宿主机设置对容器无效
innodb_flush_method=O_DIRECT为什么单独启用没用？
innodb_flush_method=O_DIRECT只绕过OS page cache写.ibd数据文件，但redo log默认仍走OS cache。buffer pool和log buffer在内存里抢页，反而加剧page reclaim，推高swap倾向。
- 必须配合
swappiness=1和memlock才有效，否则只是半截子工程 - 启用后
innodb_buffer_pool_size实际占用更“实”，原来设80%的现在得压到≤70%，否则启动失败 - 验证是否真正生效：
SHOW VARIABLES LIKE 'innodb_flush_method'输出必须是O_DIRECT，不是空或async_unbuffered - 用
strace -e trace=io_submit,write,pread64 -p $(pgrep mysqld)观察是否有write()调用；若有，说明仍在走page cache
NUMA架构下抖动特别难排查？
现象是vmstat显示si/so波动，但free -h显示可用内存充足。这时候很可能是MySQL进程跨NUMA节点分配内存，触发远端内存访问+隐式换页。
- 运行
numastat -p $(pgrep mysqld)，看numa_miss是否持续 >5% - 检查systemd service文件是否误加了
numactl --interleave=all——它会让cgroup强制回收内存，干扰内核NUMA感知逻辑 - 多路Xeon服务器上，需额外配
innodb_numa_interleave=ON，或确保启动时未被numactl包裹 - 别只盯着
innodb_buffer_pool_size，InnoDB内部结构（如log_sys、dict_sys）也吃内存，总开销比配置值高10–15%
真正让MySQL免疫Swap，不是调一个参数，而是三件套齐备：swappiness=1压制倾向、memlock unlimited锁住进程、O_DIRECT减少缓存争抢——少一个，抖动就可能在半夜复现。
