MySQL 硬體層效能優化全攻略：CPU、NUMA、Swap、檔案系統、RAID 與 FlashCache

MySQL 硬體層效能優化全攻略

資料庫效能不僅取決於 SQL 優化與索引設計，底層硬體與作業系統調校同樣關鍵。本文系統整理 CPU 性能模式、NUMA 架構、Swappiness、檔案系統掛載參數、I/O 排程器、RAID 卡設定、FlashCache 部署與 InnoDB 參數調優，構建從鐵到軟的完整優化知識體系。

一、CPU 最大效能模式

MySQL 對 CPU 核心的利用演進

核心原則：一條 Query 對應一個邏輯 CPU。核心數不足會導致並發查詢排隊，核心數過多則上下文切換開銷增大。

CPU 降頻陷阱與解決

現代 Intel CPU（如 E5-2620）支援節能模式，閒置時自動降頻（如 2.0GHz 降至 1.2GHz），省電但嚴重影響 MySQL 突發效能。

# 查看實際頻率
cat /proc/cpuinfo | grep "cpu MHz"

解決方案（三選一即可）：

1. BIOS 設定：進入 BIOS，將 Power Management → CPU Power Management → Performance Mode 設為 Maximum Performance。
2. OS 層面：安裝 cpupower，設定 performance 模式：

   yum install kernel-tools -y
   cpupower frequency-set -g performance

3. Kernel 參數：啟動參數加入 intel_pstate=disable 關閉 p-state 驅動，改用 acpi-cpufreq。

二、關閉 NUMA（非一致性記憶體存取）

NUMA vs SMP 架構差異

• SMP：所有 CPU 共享同一記憶體控制器，存取延遲均等。
• NUMA：CPU 分組為節點，各節點有本地記憶體。本地存取快，跨節點存取慢。

MySQL 啟動時若被排程到某 NUMA 節點，記憶體分配傾向該節點。當本地記憶體耗盡，Linux 會觸發 Swap 而非跨節點分配，導致效能崩塌。

關閉 NUMA 三種方式

1. BIOS 關閉：最徹底，重開機生效。
2. 啟動 MySQL 時綁定：

   numactl --interleave=all mysqld &

3. Kernel 參數關閉（永久生效）：

   # 編輯 /etc/default/grub
   GRUB_CMDLINE_LINUX="... numa=off"
   update-grub && reboot

同時建議設定 vm.zone_reclaim_mode=0（/etc/sysctl.conf），避免區域記憶體回收觸發 Swap。

三、關閉 Swap（vm.swappiness = 0）

Swappiness 機制

• 值域 0~100，預設 60。
• 0：極力避免 Swap，優先回收 Page Cache。
• 100：積極將 Inactive 頁面換出。

InnoDB 自管理 Buffer Pool，OS 將其視為 Inactive 記憶體並錯誤 Swap 出去，會造成大量 CPU/IO 浪費。

永久設定

echo "vm.swappiness = 0" >> /etc/sysctl.conf
sysctl -p

注意：vm.swappiness=0 不代表完全禁用 Swap（需 swapoff -a），但能最大程度保護 InnoDB 記憶體。

四、檔案系統優化

掛載參數：noatime + nobarrier

# /etc/fstab 範例
/dev/sdb1  /data  ext4  defaults,noatime,nobarrier  0  0

I/O 排程器：Deadline 為王

• CFQ：預設，公平但對小 IO 延遲敏感，大量連續 IO 會餓死小請求。
• Deadline：保證請求不會無限等待，資料庫負載表現最穩定。
• NOOP：FIFO 無優化，適合 NVMe/快閃無磁頭尋道設備。

即時切換：

echo deadline > /sys/block/sda/queue/scheduler

永久生效（Kernel 參數）：

# /etc/default/grub
GRUB_CMDLINE_LINUX="... elevator=deadline"

區塊裝置微調

# 減少預讀（預設 128KB → 16KB）
echo 16 > /sys/block/sdb/queue/read_ahead_kb
# 增大請求佇列（預設 128 → 512）
echo 512 > /sys/block/sdb/queue/nr_requests

五、RAID 卡優化

電池學習週期：約 90 天充放電一次，電量低會自動降級為 Write Through（效能驟降）。

應對策略：

1. 人工觸發學習（業務低峰期）。
2. 強制 Force Write Back（風險：掉電丟資料，需權衡）。

六、FlashCache 部署（SSD 做 HDD 快取）

# 建立 FlashCache，block size 4K 對齊 InnoDB page size
flashcache_create -b 4k cachedev /dev/sdc /dev/sdb
# /dev/sdc = SSD，/dev/sdb = HDD

關鍵參數調優

flashcache.fast_remove = 1          # 關機不回寫髒塊，加速關機
flashcache.reclaim_policy = 1       # LRU 淘汰策略（0=FIFO）
flashcache.dirty_thresh_pct = 90    # 髒塊閾值 90%
flashcache.cache_all = 1            # 快取所有內容，可用黑名單過濾
flashcache.write_merge = 1          # 開啟寫入合併，提升寫效能

七、InnoDB 參數對應硬體調優

八、總結：硬體優化檢查清單

1. ☐ CPU 設為 Performance 模式
2. ☐ 關閉 NUMA 或 numactl --interleave=all 啟動
3. ☐ vm.swappiness = 0
4. ☐ 掛載 noatime,nobarrier，I/O 排程器 deadline
5. ☐ RAID 卡：關讀快取/預讀，開 BBWC Write Back
6. ☐ FlashCache 部署（HDD + SSD 混合架構）
7. ☐ InnoDB 參數依儲存媒體微調

硬體優化是資料庫效能的地基。沒有穩固的地基，上層 SQL 調優終究是無本之木。建議將上述清單納入標準化交付流程，每台新上線 DB 伺服器必過「硬體體檢」再投入生產。