當前CPU都已是NUMA架構，相信除了歷史遺留系統，很少會有資料庫跑在SMP的CPU上了。NUMA架構帶來的優勢無言而語，CPU更快的記憶體訪問速度，但是帶來的問題也不言而喻，特別是對於資料庫的影響。MySQL之前“臭名昭著”的swap問題就是因為NUMA架構導致。大部分同學已經知道應對技巧，即在啟動檔案中加入：

numactl --interleave=all mysqld ...

or

numactl –cpunodebind=node –localalloc mysqld ...

MongoDB官方的啟動檔案大致也是這麼寫的。但是這樣的處理方式在Inside君看來並不是最優的。因為NUMA的優勢在於本地記憶體的申請速度。因此，對於資料庫來說，一個好的策略應該是諸如緩衝池這樣的全域性記憶體可以向所有節點申請記憶體，而執行緒級別的記憶體還是堅持本地分配策略。

MySQL 5.7 InnoDB提供了新的引數innodb_numa_interleave，即緩衝池記憶體的分配策略採用interleave的方式。官方文件中的說明如下：

Enables the NUMA interleave memory policy for allocation of the InnoDB buffer pool. Wheninnodb_numa_interleave is enabled, the NUMA memory policy is set to MPOL_INTERLEAVE for the mysqld process. After the InnoDB buffer pool is allocated, the NUMA memory policy is set back to MPOL_DEFAULT. For theinnodb_numa_interleave option to be available, MySQL must be compiled on a NUMA-enabled system.

實現程式碼也比較優雅，有興趣的同學可以看下。不過當你高興InnoDB終於支援NUMA特性時，MySQL又給我們潑了冷水：

[email protected]# bin/mysqld -V

bin/mysqld  Ver 5.7.12 for linux-glibc2.5 on x86_64 (MySQL Community Server (GPL))

[email protected]# bin/mysqld --help -v | grep numa

最新的5.7.12版本竟然找不到此引數。但是沒有關係，開源的魅力在於折騰，於是乎修改了2行程式碼，編譯安裝後引數innodb_numa_interleave就又出現了：

[email protected]:/mdata/mysql/mysql-5.7.12/bld# sql/mysqld -v --help | grep numa

  --innodb-numa-interleave 

innodb-numa-interleave                                       FALSE

小夥伴可嘗試自己去解決看看，第一個回覆並答對的小夥伴，將獲得姜老師提供的價值1000元的某雲服務提供商代金券一張哦~~~

不過，相比Microsoft SQL Server，MySQL的NUMA支援依然不夠完善，因為Microsoft SQL Server在2005版本就已經支援NUMA特性，並且提供了相應的命令來進行控制，如：

ALTER SERVER CONFIGURATION SET PROCESS AFFINITY CPU=0 TO 3;

這樣做的好處是，比如在多例項環境下，使用者可以更為靈活的控制記憶體的分配。但是要實現此功能，貌似也不是一件難事哦，有誰願意實現給InnoSQL貢獻自己的一份力量呢？

PS：Inside君的2016年MySQL網路培訓班又將開始啦~~~，具體點選：2016年最好的MySQL資料庫網路培訓又來了 零基礎、Oracle DBA、MySQL DBA的同學們都來吧，跟著姜老師的思考方式來系統的學習MySQL。