MySQL 效能調優不是單一參數的疊加，而是「硬體資源、引擎特性、負載模式」三角平衡的藝術。本文針對 InnoDB 為主的現代負載，梳理 9 大核心參數的調優邏輯、監控指標與實戰配置範本，並說明為什麼「複製別人的 my.cnf」是危險的。

調優前的三個前提

1. 測量基準線：sysbench/tpcc-mysql 跑分、pmm/Grafana 觀測 24h 基準指標
2. 識別瓶頸：CPU/IO/鎖/網路/記憶體？用 top/iostat/SHOW ENGINE INNODB STATUS/Performance Schema 定位
3. 明確目標：降低 P99 延遲？提升 QPS？支撐更多並發？單一目標導向調整

9 大參數調優決策表

參數	核心邏輯	調大信號	調大風險	實戰建議值 (16GB RAM, SSD, InnoDB 主流)
innodb_buffer_pool_size	資料+索引熱點快取核心	命中率 < 99%、Innodb_buffer_pool_reads 升高	超過物理記憶體 75% 觸發 Swap	10-12 GB (專用機 70%)
innodb_log_file_size	Redo log 容量，影響 checkpoint 頻率	Innodb_log_waits > 0、寫入延遲抖動	崩潰恢復時間變長	512M-1G (總容量 < buffer_pool 1/4)
max_connections	並發連線上限	Threads_connected 接近上限、報 Too many connections	每連線佔 thread_stack+sort_buffer+read_buffer 記憶體	2000-3000 (配合連線池)
table_open_cache	表定義/結構快取	Opened_tables/sec > 2	消耗檔案描述符、記憶體	4096-8192 (配合 open_files_limit=65535)
thread_cache_size	線程複用池	Threads_created/Connections > 0.1	極大無額外收益	200-500
sort_buffer_size	每連線排序緩衝	Sort_merge_passes 快速增長	每連線獨佔，500連線×8MB=4GB	2-4MB (大排序臨時調大 SESSION 級)
read_buffer_size	全表掃描順讀緩衝	大量全表掃描、Handler_read_rnd_next 高	同 sort_buffer 風險	1-2MB
join_buffer_size	無索引 JOIN 緩衝	Select_full_join 高	每 JOIN 分配，極易 OOM	256KB-1MB (優化 SQL 才是正解)
back_log	TCP 監聽隊列	連線風暴、unauthenticated user 多	受 OS somaxconn 限制	1024 (配合 sysctl net.core.somaxconn=65535)

連線與超時參數（防連線洩漏）

wait_timeout = 7200
interactive_timeout = 7200
max_connect_errors = 100000
net_read_timeout = 30
net_write_timeout = 60

慢查詢與審計

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5          # 秒級，視業務調整
log_queries_not_using_indexes = 1
log_slow_admin_statements = 1
log_slow_slave_statements = 1

配置變更安全流程

1. 測試環境套用 → 跑壓測 → 對比指標
2. 生產環境藍綠/滾動重啟（主從切換窗口）
3. 修改後持續觀測 2h+，確認無異常回滾
4. 所有變更記錄至 GitOps 倉庫，含調整原因、預期效果、回滾方案

常見誤區

• ❌ 盲目調大所有 Buffer → 記憶體爭用、Swap、OOM Killer
• ❌ 忽略 OS 層限制（ulimit -n、vm.swappiness、transparent_hugepage）
• ❌ 只看 QPS 不看 P99/P999 延遲
• ❌ 參數調優替代 SQL 優化（索引、改寫、分頁優化才是一階導數）

---

調優是「減法藝術」：先優化 SQL 與索引，再調整參數服務於優化後的負載。將參數配置納入基礎設施代碼，配合自動化巡檢（pt-variable-advisor、mysqlcheck），才能在規模增長中保持穩定高效。