numa_miss高说明mysqld正频繁跨节点访问内存，需立即绑定cpu与内存节点、禁用透明大页、锁定后台线程亲和性，并验证numa_maps中heap分配是否集中于本地节点（如n0=），否则所有优化均失效。
numastat -p $(pgrep mysqld) 显示 numa_miss 高怎么办
这说明 mysqld 正在频繁从远端 NUMA 节点分配内存，是 NUMA 问题最直接的证据。不是“可能有问题”，而是已经发生跨节点访问抖动。
关键看三列：numa_hit 应该 >95%，numa_miss 和 numa_foreign 同时升高，基本可断定 buffer pool 或线程堆内存没落在本地节点。
- 先确认当前绑定状态：
numactl --show和cat /proc/$(pgrep mysqld)/status | grep -i "mem" - 检查
innodb_buffer_pool_size是否超过单个节点可用内存（查numastat输出中各 node 的Free值，留 20% 余量） - 若使用 systemd 启动，
ExecStart必须显式调用numactl，不能只改mysqld_safe或依赖默认启动脚本
systemd 里加 numactl 启动失败报 Permission denied
这是最常见的实操卡点：systemd 默认禁止进程绑定 CPU/内存节点，因为需要 CAP_SYS_NICE 和 CAP_SYS_RESOURCE 能力，且 numactl --membind 必须由 root 执行。
直接在 ExecStart= 前加 numactl 会失败，错误通常是 Operation not permitted 或 Cannot allocate memory。
- 在 service 文件中添加：
CapabilityBoundingSet=CAP_SYS_NICE CAP_SYS_RESOURCE - 禁用 cgroup 内存统计干扰：
MemoryAccounting=false（尤其 cgroup v1 下，它会覆盖--membind） - 启动命令必须写全路径：
ExecStart=/usr/bin/numactl --cpunodebind=0 --membind=0 /usr/sbin/mysqld $MYSQLD_OPTS
明明绑定了 Node 0，numa_maps 还看到 N1= 分配
这往往不是绑定失效，而是透明大页（transparent_hugepage）在捣鬼。它会绕过 --membind 策略，强行从任意节点分配 2MB 大页，导致 numa_maps 里出现大量 N1= 或 interleave:1。
验证方式：cat /sys/kernel/mm/transparent_hugepage/enabled 如果输出含 [always] 或 [madvise]，就必须关掉。
- 临时关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久关闭：在 GRUB_CMDLINE_LINUX 中加
transparent_hugepage=never，然后update-grub && reboot - 别信
numactl --interleave=all：它只是让分配轮询所有节点，不解决本地化问题，反而加剧抖动
buffer pool dump 后命中率高，但性能还是差
SHOW ENGINE INNODB STATUS 或 innodb_buffer_pool_dump_now=ON 只反映逻辑缓存效率，完全不体现物理内存位置。99% 的 buffer pool 命中率 + 40% 的 numa_miss 是常见组合——数据在内存里，但不在本地节点上。
真正要盯的是内核级映射：sudo cat /proc/$(pgrep mysqld)/numa_maps | awk '$NF ~ /heap/ {print $4}' | sort | uniq -c。输出应几乎全是 N0= 或 interleave:0。
- 如果看到大量
N1=，说明 InnoDB 后台线程（如log_writer、page_cleaner）被调度到了 Node 1 的 CPU 上，正在远程访问 Node 0 的 buffer pool - 此时需配合
pidstat -t -p $(pgrep mysqld) 1 5查迁移次数，再用taskset -cp锁定关键线程到 Node 0 CPU - MySQL 5.7.9+ 支持
innodb_numa_interleave=OFF，但仅控制 buffer pool 初始化，不约束运行时线程调度
