MySQL在NUMA服务器上CPU不均和卡顿，大概率是线程漂移与跨节点内存访问所致；需用numastat -c mysql查other_node>20%、pidstat看migrate>3/秒、numactl --show --pid确认绑定策略，并关闭transparent_hugepage、绑定线程与本地内存。
MySQL在NUMA服务器上出现CPU利用不均和卡顿，大概率不是CPU不够用，而是线程在节点间漂移、内存跨节点访问导致延迟翻倍；必须用numastat确认跨节点访问占比，再结合pidstat和taskset定位线程调度失配。
怎么看是不是NUMA导致的CPU不均？
别只盯着top或htop里各核的使用率——它们看不出线程是否在NUMA节点间乱跳。真正要查的是进程实际运行在哪、内存又落在哪：
-
numastat -c mysql：重点看other_node列，持续超过20%就危险；numa_miss和numa_foreign若每秒增长明显，说明Buffer Pool正被远程节点“截胡” -
pidstat -t -p $(pgrep mysqld) 1 5 | grep migrate：每秒迁移次数＞3，代表连接线程频繁跨节点调度 -
numactl --show --pid $(pgrep mysqld)：确认当前mysqld进程绑定策略，若显示preferred或空值，说明没做任何约束 - 用
lscpu | grep -E 'Socket|NUMA'先搞清拓扑：比如NUMA node0 CPU(s): 0-63，意味着Node 0管前64个逻辑核
为什么numactl --interleave=all有时更卡？
这个命令看似“一碗水端平”，实则让InnoDB Buffer Pool页帧随机散落各节点，而线程仍可能被调度到非本地节点执行，结果仍是跨节点访问。尤其当innodb_buffer_pool_instances远小于NUMA节点数时，问题更突出：
- 单实例OLTP主库（如电商核心库）：优先用
numactl --cpunodebind=0 --membind=0，强制全堆在Node 0，前提是innodb_buffer_pool_size ≤ Node 0可用内存 × 0.8 - 多实例或混合负载（如备库+ETL）：才考虑
--interleave=all，但必须同步调大innodb_buffer_pool_instances（建议≥ NUMA节点数） - 绝对不要在systemd服务里直接写
ExecStart=numactl ... mysqld：systemd默认禁用CAP_SYS_NICE，绑定会静默失败；得加CapabilityBoundingSet=CAP_SYS_NICE CAP_SYS_RESOURCE
必须关掉transparent_hugepage才能生效
numactl对大页无效——内核会绕过你的--membind，直接从任意节点分配2MB页。不关它，其他所有绑定操作都白搭：
- 检查状态：
cat /sys/kernel/mm/transparent_hugepage/enabled，若含[always]或[madvise]，就得关 - 临时关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久生效：在
/etc/default/grub的GRUB_CMDLINE_LINUX里加transparent_hugepage=never，再update-grub && reboot - 验证：
grep AnonHugePages /proc/meminfo输出应为0
线程亲和性比内存绑定更关键
MySQL自己不控制线程绑核，全靠Linux CFS调度。即使Buffer Pool全在Node 0，线程跑到Node 1执行，照样触发远程访问：
- 用
taskset -c 0-31 mysqld启动（假设Node 0有32核），再配合--membind=0，numastat -p里的numa_hit通常能从70%升至92%+ - 避免用
mysqld_safe：它会覆盖numactl环境变量，改用直接调mysqld二进制 - 如果启用了
innodb_numa_interleave=ON（MySQL 8.0.27+），它只影响Buffer Pool分配，不控制线程位置，仍需额外绑核
NUMA优化最易被忽略的点是：它不是一次性配置，而是CPU调度、内存分配、内核参数三者联动的结果；关transparent_hugepage是前提，taskset或numactl --cpunodebind控线程是关键，--membind或--interleave配内存是配套——少一个，延迟就可能悄悄翻倍。
