瓶頸本質：最終都歸結於 I/O、記憶體、CPU
任何系統極限皆在三大資源。MySQL 典型瓶頸為 I/O，因為熱資料永遠大於記憶體。調優必須有序：先確認瓶頸層級，再針對性投入資源。
CPU 選型：頻率 > 核心數
- MySQL 單查詢無法跨核並行，復制單執行緒同樣受限於單核效能。
- 鎖競爭場景下，高主頻 CPU 能縮短關鍵區持有時間，吞吐更高。
- 64 位元架構為必選，突破 4GB 記憶體限制，充分利用大頁面記憶體。
多核價值在於並發連線處理：不同連線分派不同核心，提升整體並發容量。
並發兩大維度
- 邏輯並發：應用層資源競爭，可透過調整儲存引擎（InnoDB 行鎖 vs MyISAM 表鎖）或事務隔離等級緩解。
- 內部並發：InnoDB 信號量、緩衝池頁面鎖競爭，屬引擎內部實作，需依版本優化參數（如
innodb_spin_wait_delay、innodb_sync_spin_loops）。
儲存子系統：順序 I/O 擊敗隨機 I/O
- 資料庫屬隨機讀寫密集，機械硬碟須關注平均尋道時間與 IOPS。
- RAID 10 兼顧冗余與效能，優於 RAID 5 寫入效能。
- InnoDB 透過 Change Buffer、Doublewrite Buffer、Redo Log 將隨機寫轉順序寫，實現「寫入合併、異步刷盤」。
Working Set 與記憶體規劃
Working Set = 熱點索引 + 熱點資料。原則：Working Set ≤ 實體記憶體 × 70%（留 30% 給 OS Cache 及連線緩衝）。InnoDB 以 16KB 頁為單位管理緩衝池，優秀的聚簇索引設計能最大化頁面利用率。
避坑原則
- 別為榨乾 CPU 犧牲 I/O 頻寬或記憶體。
- 系統最脆弱環節決定整體上限（木桶效應）。
- I/O 密集型業務優先投資低延遲儲存（NVMe/SSD），而非單純堆 CPU。
