MySQL 作為全球最流行的開源數據庫，廣泛支撐著高並發、大數據量的業務系統。隨著業務增長，如何將 MySQL 性能壓榨到極致成為 DBA 與開發者的必修課。本文彙總 101 條實戰調優建議，涵蓋服務器硬件選型、操作系統調優、MySQL 核心參數配置、數據庫模式設計、查詢優化等五大維度，助你構建高性能、高可用的數據庫系統。
一、服務器硬件與作業系統調優（第 1-24 條）
1. 內存策略：盡可能將熱數據載入內存
- 第 1 條：配置足夠物理內存，使整個 InnoDB 文件（數據+索引）能載入內存。內存訪問速度比磁盤快數個數量級。
- 第 2 條：不惜一切代價避免 Swap 交換分區使用。Swap 觸發意味著磁盤 I/O，會導致嚴重性能抖動。
- 第 3 條：使用帶電池備用的 RAID 卡緩存（BBWC/FBWC），保證寫入緩存掉電不丟失。
2. 磁盤與存儲架構
- 第 4 條：優先選擇 RAID 10，兼顧讀寫性能與數據安全；避免 RAID 5（第 5 條），其校驗計算開銷大，重建風險高。
- 第 6-7 條：OS、數據、臨時空間、Binlog 物理隔離不同磁盤/分區，消除 I/O 爭搶。
- 第 8-11 條：更多磁盤 = 更高 IOPS；小容量高轉速硬盤（SAS 15K）優於大容量低轉速；SAS 優於 SATA；NVMe SSD 為極致性能首選。
- 第 14 條：核心業務可考慮 PCIe 固態 IO 卡（如 Intel Optane），提供微秒級延遲與 GB/s 級吞吐。
3. 文件系統與內核參數
- 第 15 條：Linux 設置
vm.swappiness=0，盡量不使用 Swap（需配合足夠內存）。
- 第 16 條：掛載數據目錄加
noatime,nodiratime，減少元數據寫入。
- 第 17-18 條：推薦 XFS 文件系統，並調優其日志/緩衝參數；避免 ext3/4 的 double-buffering 問題。
- 第 19 條：I/O 調度器選
noop 或 deadline（SSD 推薦 noop），禁用 cfq/anticipatory。
- 第 20 條：強制使用 64 位操作系統，突破 4GB 內存限制。
4. 系統精簡與網絡
- 第 21 條：卸載無用軟件包、禁用非必要服務，減少資源佔用與攻擊面。
- 第 22 條：配置
/etc/hosts 解析應用服務器域名，消除 DNS 查詢延遲。
- 第 23 條：嚴禁
kill -9 強殺 MySQL 進程，會導致數據損壞、備份失敗。
- 第 24 條：專機專用，避免其他進程搶佔 CPU/內存/IO。
二、MySQL 核心配置參數調優（第 25-39 條）
InnoDB 核心參數
- 第 25 條：
innodb_flush_method=O_DIRECT 繞過 OS 文件系統緩存，避免雙重緩衝（Double Buffering）。
- 第 26 條：EXT3/4 下禁用 O_DIRECT（會導致寫入序列化），需配合 XFS 或原始裝置。
- 第 27 條：
innodb_buffer_pool_size 設為物理內存 60%-80%（專用機），目標：熱數據全內存化。
- 第 28 條：
innodb_log_file_size 適中（如 1-4GB），過大延長崩潰恢復時間，過小導致頻繁 checkpoint 刷盤。
- 第 29 條：勿混用
innodb_thread_concurrency 與 thread_concurrency，建議置 0 讓引擎自適應。
連接與緩存管理
- 第 30 條：
max_connections 設合理上限（如 1000-2000），防止連接爆發耗盡內存導致 OOM Killer。
- 第 31 條：
thread_cache_size 設 16-64，減少線程創建/銷毀開銷。
- 第 32 條：啟用
skip-name-resolve，跳過 DNS 反解析，加速連接建立。
查詢緩存與臨時表
- 第 33 條：查詢緩存（
query_cache_type）僅適用「讀多寫少、數據變更極低」場景；高寫入下會成為鎖爭用熱點，建議關閉。
- 第 34-35 條：適當增大
tmp_table_size、max_heap_table_size（如 64-256MB），減少內部臨時表落盤。
- 第 36 條：
sort_buffer_size 勿設過大（建議 1-4MB），它是會話級內存，併發高時極易 OOM。
索引緩存與事務刷盤
- 第 37 條：監控
Key_read_requests / Key_reads 比率 > 100:1，調整 key_buffer_size（MyISAM 專用）。
- 第 38 條：
innodb_flush_log_at_trx_commit=1 保證 ACID；極致性能可設 0/2，但需承擔最多 1 秒數據丟失風險。
- 第 39 條：必須擁有獨立測試環境，驗證配置變更影響，支持無損重啟演練。
三、數據庫模式設計與架構優化（第 40-59 條）
範式與反範式平衡
- 第 40-41 條：保持表結構清晰，定期歸檔冷數據（按時間/業務分表/分庫），縮小活躍數據集。
- 第 42-43 條：按查詢模式建立索引，但避免過度索引（寫入放大、優化器誤判）。單表索引建議 ≤ 5 個。
- 第 44 條：大文本/BLOB 字段啟用壓縮（
COMPRESSED 行格式或應用層壓縮），節省空間減少 I/O。
字符集與數據類型選型
- 第 45 條：UTF8MB4 比 latin1 佔用更多空間，若無多語言需求，latin1/ascii 更高效。
- 第 49 條：選用「剛好夠用」的最小數據類型：
TINYINT vs INT，CHAR(32) vs VARCHAR(255)。
- 第 50 條：低頻訪問的大字段（BLOB/TEXT/JSON）拆分到獨立表（垂直分表），避免掃描主表時讀取無用數據。
存儲引擎與特殊場景
- 第 54 條：按業務選引擎：InnoDB（事務/高併發）、MyISAM（只讀/全文）、Archive（日志/審計）、Memory（臨時聚合）。
- 第 55 條：日志/審計表用 Archive 引擎，僅支持插入/全表掃描，壓縮率極高。
- 第 56 條：Session 數據存 Redis/Memcached，利用 TTL 自動過期，避免 MySQL 寫入風暴與鎖爭用。
- 第 57 條：變長字符串優先
VARCHAR（UTF8MB4 下 CHAR 固定長度浪費空間）。
DDL 與變更管理
- 第 53 條：大表加列時，先
DROP INDEX → ADD COLUMN → ADD INDEX，避免重建索引開銷。
- 第 58-59 條：DDL 變更小步快跑，先在預發/測試環境驗證，使用
pt-online-schema-change 或 gh-ost 實現無鎖變更。
四、查詢優化與執行計劃分析（核心補充）
除上述 101 條外，以下核心原則貫穿始終：
- EXPLAIN 是起點：關注
type（目標 ref/range/eq_ref）、key、rows、Extra（Using index/where/filesort/temporary）。
- 覆蓋索引：查詢列包含在索引中，避免回表，性能提升數量級。
- 避免隱式轉換：
WHERE varchar_col = 123 導致全表掃描，字符串必須加引號。
- 範圍列優化：複合索引最左前綴原則，範圍列（>、<、>=、<=、LIKE %...）後的列無法用到索引。
- LIMIT 深分頁：
LIMIT 1000000, 10 極慢，改用延遲關聯或游標分頁（WHERE id > last_id LIMIT 10）。
- COUNT(*) 誤區：InnoDB 無統計元數據，
COUNT(*) 需全表掃描；計數場景用 Redis 維護或單獨統計表。
五、監控與持續優化體系
- 建立核心指標儀表盤：QPS/TPS、慢查詢數、緩存命中率、InnoDB 行鎖等待、磁盤 I/O 利用率、主從延遲。
- 慢查詢日志（
long_query_time=0.5）+ pt-query-digest 定期分析 Top SQL。
- 定期
ANALYZE TABLE 更新統計信息，確保優化器決策準確。
- 主從架構下，讀寫分離需考慮延遲容忍度，關鍵業務強制走主庫。
結語
MySQL 調優無銀彈，唯有「硬件奠基、配置為本、架構制勝、SQL 為王、監控護航」的系統性工程。將這 101 條建議內化為肌肉記憶，結合具體業務場景靈活取捨，方能駕馭萬億級數據洪流。建議收藏本文，每次排查性能問題時對照檢視，必有所獲。