MySQL 效能瓶頸往往不在單一層面，而是硬體資源、作業系統調度、資料庫參數與 SQL 寫法共同作用的結果。本文從硬體層、系統層、MySQL 層三個維度，梳理經驗驗證的優化策略，適合 DBA 與架構師參考落地。
在 BIOS 層面調整：
Performance Per Watt Optimized (DAPC)，資料庫屬計算密集型，勿啟用省電Maximum Performancenumactl --interleave=all 的運行時開銷按效能提升幅度排序：
Write Back (WB) 或 Force WB（雙電源保護下），嚴禁 Write Through (WT)；預讀策略通常雞肋，關閉deadline 或 noop（SSD/NVMe），禁用 cfq（不適合資料庫隨機 I/O）noatime,nodiratime,nobarrier（XFS 專屬），減少 metadata 寫入、關閉屏障提升吞吐| 參數 | 建議值 | 作用 |
|---|---|---|
| vm.swappiness | 5~10 (RHEL7+ 慎設 0) | 降低 Swap 傾向，防 OOM Killer |
| vm.dirty_background_ratio | 5~10 | 背景回寫觸發閾值，平滑 I/O 波峰 |
| vm.dirty_ratio | 背景值的 2 倍 | 強制同步觸發閾值，避免大量髒頁一次刷盤阻塞 |
| net.ipv4.tcp_tw_recycle / reuse | 1 | 加速 TIME_WAIT 回收，提升高併發短連接效率 |
備註：read_ahead_kb、nr_requests 對 OLTP 混合讀寫影響有限，可按實測調整。
[mysqld] # 引擎與儲存 default-storage-engine = InnoDB innodb_file_per_table = 1 innodb_data_file_path = ibdata1:1G:autoextend # 避免 10M 預設頻繁擴展 # 緩衝池：單實例純 InnoDB 設物理記憶體 50~70% innodb_buffer_pool_size = 64G # Redo Log：預設 48MB 太小，建議 256M * 2 組 innodb_log_file_size = 256M innodb_log_files_in_group = 2 # 持久化策略：三檔選一 # 強一致：innodb_flush_log_at_trx_commit=1, sync_binlog=1 # 折中：2 和 10（允許秒級丟失） # 高效能不怕丟：0 和 0（從庫重做即可） # 連接與緩衝 max_connections = 2000 max_connect_errors = 100000 open_files_limit = 65535 table_open_cache = 20000 table_definition_cache = 20000 innodb_open_files = 20000 # 會話級緩衝：切勿設大，防 OOM tmp_table_size = 64M max_heap_table_size = 64M sort_buffer_size = 2M join_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 2M # 慢查詢 long_query_time = 0.05 # 50ms，5.5+ 支援微秒級 slow_query_log = 1 # 廢棄 MyISAM 相關 key_buffer_size = 32M query_cache_type = 0 query_cache_size = 0
NOT NULL，效能與儲存雙贏SELECT * 觸發離頁讀取SELECT id FROM t WHERE ... ORDER BY id LIMIT 100000,20 → 先取 ID 再回表 JOINpt-duplicate-key-checker 清理重複索引，pt-index-usage 清理低頻索引pt-query-digest + Anemometer 平台化分析pt-kill 殺長查詢，Percona 專屬 innodb_kill_idle_transactionpt-online-schema-changept-table-checksum + pt-table-sync效能調優無銀彈，只有在正確的層面做正確的事。建議按「硬體→系統→實例參數→SQL→架構」順序疊加驗證，每步留存基準線對比。持續觀測、持續優化，才是 DBA 的核心價值。
