絕大多數中小型網站運行在 LAMP（Linux + Apache + MySQL + PHP）架構之上，而 MySQL 往往成為整個系統的效能瓶頸。針對 Linux 作業系統層面進行 MySQL 優化，能顯著提升資料庫吞吐量與回應速度。本文將從 CPU、記憶體、檔案系統三大維度，提供通用且實用的優化策略。

一、CPU：關閉節能模式，釋放完整算力

現代伺服器 CPU（如 Intel Xeon E5 系列）普遍支援動態調頻技術。當系統負載較低時，作業系統會配合硬體降低 CPU 頻率以省電降溫。雖然環保，但對追求高併發、低延遲的 MySQL 而言，頻率波動會導致查詢執行時間不穩定，甚至成為效能殺手。

檢測方法： 執行 cat /proc/cpuinfo 查看 cpu MHz 欄位，若實際頻率遠低於標稱頻率，即處於降頻狀態。

解決方案： 在 BIOS 中將「Power Management」或「CPU C-States」設為「Performance Mode」（最大效能模式），或在作業系統層面透過 cpupower 工具鎖定最高頻率。BIOS 設定更徹底，建議優先採用。

二、記憶體：解決 NUMA 與 Swap 的隱形傷害

1. 關閉 NUMA（非一致性記憶體存取）

NUMA 架構下，CPU 存取本地記憶體速度快、遠端記憶體慢。Linux 預設的記憶體分配策略可能導致 MySQL 進程頻繁跨節點存取，甚至觸發 Swap。對資料庫而言，Swap 帶來的 I/O 延遲是災難性的。

三種關閉方式（擇一即可，BIOS 最佳）：

• BIOS 層面： 在 BIOS 中 Disable NUMA（各廠商選單不同，請參閱主機板手冊）。
• 核心參數： 編輯 /etc/grub.conf，在 kernel 行尾加入 numa=off，並設定 vm.zone_reclaim_mode=0 減少積極回收記憶體。
• 啟動時指定： 使用 numactl --interleave=all mysqld & 啟動 MySQL，強制記憶體在所有節點輪詢分配。

2. 將 vm.swappiness 設為 0

vm.swappiness 控制核心積極交換分頁到 Swap 的傾向（0-100，預設 60）。MySQL（特別是 InnoDB）自行管理緩衝池，將熱點資料留在記憶體。若核心錯將 InnoDB 的非活躍頁面換出，會造成大量無謂的 I/O 與 CPU 開銷。

永久生效：

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

三、檔案系統：減少元資料更新，優化 I/O 調度

1. 掛載參數加入 noatime、nobarrier

• noatime： 禁用 Access Time 更新。資料庫大量讀取資料檔，每次讀寫都更新 atime 會產生大量元資料寫入，毫無業務價值。
• nobarrier / barrier=0： 關閉寫入屏障。現代 RAID 卡（帶 BBU）或 NVMe SSD 具備掉電保護，屏障機制反而拖慢同步速度。ext3/ext4 用 barrier=0，XFS 用 nobarrier。

2. I/O 調度器改用 deadline

預設 CFQ（完全公平佇列）對資料庫大量隨機 I/O 不友善，易造成小查詢「餓死」。Deadline 調度器保證請求在截止時間前被服務，極大降低延遲抖動。

即時生效： echo deadline > /sys/block/sda/queue/scheduler
永久生效： 在 /etc/grub.conf kernel 行加入 elevator=deadline。

總結：優化清單速查表

層面	關鍵動作
CPU	BIOS 設定最大效能模式，禁用 C-States
記憶體	關閉 NUMA（BIOS/grub/numactl），vm.swappiness=0
檔案系統	掛載加 noatime、nobarrier；I/O 調度器改 deadline

套用上述三大策略後，重啟 MySQL 並觀察 vmstat、iostat 以及慢查詢日誌，通常能看到查詢延遲顯著下降、吞吐量穩定提升。記住：優化是持續迭代的過程，請配合實際負載持續微調。