MUMA架构
在单实例的MySQL服务器上，通过会为MySQL的Buffer Pool分配50%至70%甚至更高的内存，让MySQL 服务会尽可能多地占用系统资源。在基于NUMA系统中，内存被分配到各NUMA节点上，系统的默认为进程分配该进程所在NUMA节点的内存，而数据库应用又希望使用到所有CPU节点和内存，由于MySQL对NUMA支持不是很完善，在特殊场景中容易出现系统拥有空闲内存但发生SWAP导致性能问题的情况。
如对于2个NUMA节点64GB内存的MySQL服务器来说，为MySQL Buffer Pool配置48GB的内存，在默认NUMA策略下，会存在以下问题：
1、节点0和节点1的内存分配不平衡，内存会优先分配给节点0，节点1被用于备份，如：
2、当属于节点0的内存完全分配给节点0，如果位于NODE0上的进程调度需要大量内存，尽管节点1仍有大量空闲物理内存，也不会将NODE1上的内存分配给该进程使用，由于节点0已无空闲内存，因此会导致NODE0上部分内存被SWAP到磁盘上，引发性能问题。
非MUMA架构
在MUMA架构下，虽然访问其他节点内存的性能低于访问本地节点内存，但并不是导致性能问题的主要原因，为解决系统存在空闲内存而部分NUMA发生SWAP操作的问题，可以有以下两种解决方式：
1. 在Linux Kernel启动参数中加上numa=off（这样也会影响到其他进程使用NUMA）；
2. 在mysqld_safe脚本中加上“numactl –interleave all”来启动mysqld。
修改后MySQL内存分配如：
参数--interleave=nodes用于设定内存的交织分配模式，即系统在为多个节点分配内存空间时，将以轮询分发的方式分配给多个节点，如果当前众多的交织分配内存节点中的目标节点无法正确地分配内存空间的话，内存空间将会由其他节点来分配
查看和配置NUMA
## 查看CPU和NUMA信息
numactl --hardware
输出结果示例：
numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 node 0 size: 32546 MB node 0 free: 25682 MB node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 node 1 size: 32768 MB node 1 free: 29902 MB node distances: node 0 1 0: 10 21 1: 21 10
上面是2个NUMA节点的服务器，配置64G内存，每个节点分配32G内存，节点0的可用内存高于节点1的可用内存