許多運維工程師面對性能瓶頸時陷入「重啟大法」或盲目調參。本文提出六層優化模型,自底向上系統化定位與解決問題,構建可預測、可控制的優化體系。
優化本質是在現有硬件資源約束下,消除系統處理能力的最大限制因子。當單機優化觸及天花板,唯有橫向擴展(分庫分表、讀寫分離、叢集)方能突破。
| 資源 | 關鍵指標 | 選型建議 |
|---|---|---|
| CPU | 核心數、主頻、緩存 | 高主頻 > 多核心(MySQL 單查詢單線程),推薦 Intel Xeon Gold/Platinum |
| 內存 | 容量、頻率、ECC | InnoDB Buffer Pool 佔 60-70%,物理內存 ≥ 64GB,DDR4 3200+ ECC |
| 存儲 | IOPS、延遲、吞吐 | NVMe SSD 必選,RAID 10,預留 20% 過備份空間 |
| 網絡 | 帶延遲、丟包率 | 萬兆網卡,單獨管理網段,啟用 RSS/RFS |
採購參考:雲服務器選擇「高 I/O 型」或「內存優化型」實例,關注基準測試分數而非僅看配置參數。
vm.swappiness = 1
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
echo never > /sys/kernel/mm/transparent_hugepage/enabled),避免內存碎片與延遲抖動隨業務演進選擇適配架構:
架構升級須配合應用端改造(連接池、重試、熔斷),不可單方面推進。
關鍵參數分類調優:
| 類別 | 核心參數 | 調優方向 |
|---|---|---|
| 內存 | innodb_buffer_pool_size, innodb_log_buffer_size, tmp_table_size, max_heap_table_size | Buffer Pool 佔物理內存 60-70%,日誌緩存 64-256MB |
| 並發 | max_connections, thread_cache_size, table_open_cache, innodb_thread_concurrency | 連接數預留 20% 余量,線程緩存命中率 > 90% |
| 日誌 | innodb_flush_log_at_trx_commit, sync_binlog, innodb_log_file_size, innodb_log_files_in_group | 雙 1 配置(最高安全),日誌文件 1-4GB,組員 2-4 個 |
| I/O | innodb_io_capacity, innodb_io_capacity_max, innodb_flush_method, innodb_use_native_aio | 根據 SSD IOPS 設置,O_DIRECT + Native AIO |
| 優化器 | optimizer_switch, eq_range_index_dive_limit, range_optimizer_max_mem_size | 關閉無用優化(如 MRR、BKA),限制範圍優化內存 |