數據庫上線前的容量規劃是保障系統穩定運行的關鍵環節。本文系統梳理MySQL性能容量評估的核心指標、業務特徵分析方法，並通過網易雲音樂、網易理財兩個真實案例演示完整評估流程。
容量評估旨在：分析上線業務場景 → 評估服務器性能指標 → 預判瓶頸資源 → 指導調優與採購。
| 指標 | 關注點 | 升級路徑 |
|---|---|---|
| 磁盤I/O性能 | IOPS、吞吐量、延遲 | 單盤→RAID陣列→SAS/SATA→SSD/NVMe |
| 內存容量 | 緩衝池大小、熱數據駐留 | 較小→較大，關注內存頻率與通道數 |
| CPU算力 | 核心數、主頻、超線程 | 普通→多核→高主頻→超線程 |
| 網絡吞吐量 | 帶寬、PPS、連接數 | 千兆→萬兆→多網卡綁定 |
| 磁盤容量 | 總存儲、增長預留、RAID損耗 | 單盤→陣列→LVM動態擴容 |
典型分層：熱數據（SSD/內存表）→ 温數據（SAS/HDD）→ 冷數據（歸檔庫/對象存儲/大數據平台）。
核心原則：性能滿足業務SLA前提下，最小化TCO（總擁有成本）。避免過度採購，關鍵資源冗餘2倍，非關鍵資源按需擴容。
| 維度 | 分析過程 | 結論 |
|---|---|---|
| 業務類型 | 歌曲信息查詢為主，用戶只讀 | OLTP，讀寫比 100:1 |
| 並發請求 | 50台應用服 × 100連接 = 5000 QPS峰值 | CPU需求高 |
| 數據總量 | 5000萬首 × 8KB = 400GB，增長緩慢 | 磁盤 > 400GB（預留2倍=800GB+） |
| 冷熱比例 | 40%歌曲被訪問，10%熱點，熱數據 < 40GB | 內存 > 40GB（建議64-128GB） |
| 分級存儲 | 無用戶產生數據，歌曲信息不可分級 | 單層存儲 |
| 網絡流量 | 8KB × 2500 QPS ≈ 20MB/s | 千兆網卡滿足，預留萬兆 |
| 維度 | 分析過程 | 結論 |
|---|---|---|
| 業務特徵 | 特定高息產品秒殺，短時極高並發寫入；平時低頻查詢 | 按峰值設計 |
| 並發請求 | 30台應用服，預估2000 TPS（3萬單/15秒） | CPU高、網絡高 |
| 讀寫比例 | 峰值全寫入，寫入為主 | 磁盤I/O極高要求（SSD/NVMe必選） |
| 數據總量 | 年百萬單位級，單筆大，總量 < 200GB | 磁盤容量一般（>200GB） |
| 冷熱數據 | 峰值產生3萬單，髒頁 < 10GB | 內存一般（>10GB，建議32GB+） |
| 分級存儲 | 前台展示半年，半年前遷歷史庫 | 按時間分區/分表歸檔 |
| 業務特徵 | 關鍵資源 | 硬件選型方向 |
|---|---|---|
| OLTP/OLAP | - | 決定架構模式 |
| 並發請求高 | CPU | 多核、高主頻、超線程 |
| 讀多寫少 | 內存 | 大內存、高頻率 |
| 寫多讀少 | 磁盤I/O | NVMe SSD、RAID 10 |
| 數據總量大 | 磁盤容量 | 大容量HDD + LVM/分布式存儲 |
| 熱數據多 | 內存 | 內存≥熱數據量 |
| 分級存儲 | - | 多介質混合部署 |
容量評估不是一次性工作，需隨業務演進持續複盤。建議建立「評估→上線→監控→複盤→再評估」閉環機制，讓數據庫架構始終匹配業務發展階段。
