背景：Pinterest 的 MySQL 效能挑戰

Pinterest 早期 MySQL 完全運行於 AWS，採用 SSD RAID-0 的 i2.2xlarge 實例，峰值 2000 QPS，單點查詢為主。然而寫入 IOPS 一旦超過 800 即出現不可接受的延遲與主從複製滯後，嚴重拖慢 ETL 批次作業。面臨「升級實例成本翻倍」或「優化現有系統」的抉擇，團隊選擇後者。

關鍵發現：Linux 核心版本決定 SSD 效能上限

• Ubuntu 12.04 預設核心 3.2：sysbench 隨機寫僅 100 MB/s
• 升級核心 3.8：同測試達 350 MB/s (提升 3.5 倍)
• 但仍遠低於硬體理論值，顯示還有 OS 層面與 MySQL 參數調優空間

系統性實驗：60 組 sysbench 測試找出最佳組合

測試維度：核心版本、檔案系統、掛載選項、RAID 區塊大小。再輔以 20 組 OLTP 測試驗證。測試方法：每組跑 1 小時、每秒採樣、捨棄前 600 秒暖機數據。

六大優化組合對比 (16/32 threads)

代號	配置內容
CURRENT	核心 3.2 + 預設 MySQL
STOCK	核心 3.18 + 預設 MySQL
KERNEL	核心 3.18 + IO/記憶體 sysctl 微調
MySQL	核心 3.18 + 優化 MySQL 參數
KERN+MySQL	核心 3.18 + sysctl + MySQL 參數
ALL	核心 3.18 + sysctl + MySQL 參數 + jemalloc

驚人成果

• 讀寫吞吐量提升 ~500%：16/32 threads 下從 4100~4600 QPS 衝至 22000~25000+ QPS
• 寫入 QPS 從 1000 升至 5100~6000
• P99 延遲降低 ~500 ms：客戶端從 15~35ms (尖峰 >100ms) 降至穩定 15ms；伺服端從 5~15ms 降至穩定 5ms
• 生產環境上線後：尖峰吞吐量 +50%、分頁告警從月 300 降至雙月個位數

核心優化清單 (可直接套用)

1. 升級 Linux 核心至 3.18+ (或更新的 LTS 版本)
2. 檔案系統掛載選項：noatime,nodiratime,discard
3. RAID 區塊大小：依工作負載調整 (如 64KB/256KB)
4. sysctl 關鍵參數：

   vm.dirty_ratio = 10
   vm.dirty_background_ratio = 5
   vm.swappiness = 1

5. MySQL 關鍵參數 (my.cnf)：

   innodb_buffer_pool_size = 70% 實體記憶體
   innodb_flush_method = O_DIRECT
   innodb_log_file_size = 1G
   innodb_log_files_in_group = 2
   innodb_flush_log_at_trx_commit = 2 (可接受 1 秒資料損失換高寫入)
   sync_binlog = 0 (非金融級可關閉)
   innodb_io_capacity = 20000 (SSD)
   innodb_read_io_threads = 16
   innodb_write_io_threads = 16

6. 改用 jemalloc 替代 glibc malloc，減少記憶體碎片與鎖競爭

結語

不需擴充硬體，僅透過核心升級、OS 參數微調、MySQL 核心配置優化與記憶體分配器替換，即可獲得數倍效能提升與極致穩定度。這正是「以軟體定義效能」的最佳實證。