MySQL进程必须绑定特定NUMA节点，否则mysqld调度与Buffer Pool内存分配错配会导致numa_miss激增、延迟上升30%~50%；需用numastat -p验证numa_hit>90%，结合numa_maps查内存段归属，并同步对齐网卡中断亲和性、禁用transparent_hugepage、配置systemd能力集及合理设置innodb_buffer_pool_instances。
MySQL进程必须绑定到特定NUMA节点，不能只靠内核自动分配
MySQL在多NUMA节点服务器上默认不感知拓扑，mysqld进程可能被调度到Node 1，而Buffer Pool内存却落在Node 0——这种错配会导致大量numa_miss，实测延迟增加30%~50%。你不能依赖top或htop显示的CPU占用率判断归属，它们不反映内存实际落点。
验证方法：numastat -p $(pgrep mysqld)，重点看Heap行的numa_hit占比；低于90%就说明问题已发生。更直接的是查/proc/$(pgrep mysqld)/numa_maps，观察各内存段的N0、N1前缀分布。
- 单实例高吞吐（如OLTP主库）：用
numactl --cpunodebind=0 --membind=0强制全部落在Node 0，前提是innodb_buffer_pool_size≤ Node 0可用内存 × 0.8 - 多实例或混合负载（如备库+ETL）：改用
numactl --interleave=all，但必须同步调大innodb_buffer_pool_instances（建议 ≥ NUMA节点数） - 绝对不要在systemd服务里直接写
ExecStart=numactl mysqld：systemd默认禁用CAP_SYS_NICE，绑定会静默失败；必须加CapabilityBoundingSet=CAP_SYS_NICE CAP_SYS_RESOURCE
网卡中断亲和性必须与MySQL所在NUMA节点对齐
网卡收包软中断（softirq）若运行在远离MySQL的NUMA节点上，每次处理网络请求都要跨节点访问Buffer Pool，等于把网络延迟和内存延迟叠加。这不是理论风险——AWS c5.metal实例上实测，错配时SELECT响应P99升高220ms。
确认当前网卡中断分布：cat /proc/interrupts | grep -i eth，看各CPU列数值是否集中在某几个核心；再用lscpu或numactl --hardware对照这些核心所属NUMA节点。
- 将网卡中断绑定到MySQL所在NUMA节点的CPU：例如MySQL绑在Node 0（CPU 0-15），执行
echo 0-15 > /proc/irq/$(cat /proc/interrupts | grep -i eth0 | awk '{print $1}' | sed 's/://')/smp_affinity_list - 启用RPS（Receive Packet Steering）辅助分发：在
/sys/class/net/eth0/queues/rx-0/rps_cpus中填入对应节点CPU掩码（如0000ffff），让软中断尽可能本地化 - 禁用irqbalance服务：它会动态迁移中断，破坏你精心设置的亲和性；
systemctl stop irqbalance & systemctl disable irqbalance
transparent_hugepage必须关闭，否则所有NUMA绑定失效
numactl --membind对2MB大页无效——内核会绕过你的策略，从任意节点分配hugepage。只要/sys/kernel/mm/transparent_hugepage/enabled含[always]或[madvise]，你就白忙活了。
检查命令：grep AnonHugePages /proc/meminfo，非0即未关干净。临时关：echo never > /sys/kernel/mm/transparent_hugepage/enabled；永久关：在/etc/default/grub的GRUB_CMDLINE_LINUX加transparent_hugepage=never，再update-grub && reboot。
- 别信“只对OLAP有用”的说法：InnoDB Buffer Pool默认就倾向使用大页，尤其当
innodb_large_prefix开启或表有长索引时 - 关闭后需重启
mysqld，因为已分配的大页不会自动释放 - 某些云厂商（如GCP N2）默认启用THP且BIOS层不可控，此时必须靠
numactl --membind+vm.zone_reclaim_mode=1组合补救
不要跳过验证环节：numa_hit > 90%只是起点，不是终点
即使numastat显示numa_hit达标，仍可能因网卡中断错位或THP残留导致性能抖动。真实压测时关注两个隐藏指标：numa_foreign持续高于5%，说明远端节点正在“截胡”新分配页；pgmajfault突增，往往意味着THP fallback触发跨节点缺页。
最简验证链：numactl --show → numastat -p $(pgrep mysqld) → cat /proc/interrupts | grep eth → perf record -e page-faults -p $(pgrep mysqld) sleep 30。四步全过，才算真正闭环。
复杂点在于网卡中断和MySQL线程池的耦合——比如thread_pool_size设为32，但只绑了16个CPU，剩余线程会被调度到远端节点，照样引发跨访存。这事容易被忽略，但后果比参数调错更隐蔽。
