MySQL集群容量规划需系统性预判业务增长、数据生命周期、查询特征与故障容忍，核心是“够用不浪费、扩容不中断、降级有余量”，分阶段估算、分类建模、预留弹性并持续验证。
规划 MySQL 集群容量不是简单加机器，而是围绕业务增长、数据生命周期、查询特征和故障容忍做系统性预判。核心是让资源“够用不浪费、扩容不中断、降级有余量”。
按业务节奏分阶段估算数据与流量
不能只看当前 QPS 或磁盘用量。要拆解：日均新增数据量（含 binlog、undo、redo）、热点表的读写比例、大事务频率、慢查询分布。例如，一个订单库若每天新增 500 万行、平均行宽 2KB，一年原始数据约 3.6TB，再叠加索引、副本、保留期（如 binlog 保存 7 天），实际存储需求可能接近 6TB。QPS 同理，需区分峰值（如秒杀）与均值，预留 2–3 倍缓冲。
- 用 pt-table-checksum 和 pt-query-digest 定期分析主从延迟与慢查模式
- 对高频更新的维度表（如用户状态表），预估其锁竞争对并发的影响
- 把业务上线节奏（如大促、新功能灰度）映射到容量里程碑，比如“双11前完成分库分表+读写分离”
选型匹配容量扩展路径
单机 MySQL 上限清晰（CPU 利用率 >70%、IO wait >30%、连接数超 80% 就该干预），但集群架构决定扩容是否平滑。MHA + 主从适合中小规模，扩容靠加从库；MySQL Group Replication 或 InnoDB Cluster 对一致性要求高，但写入吞吐受限于多数派投票；而基于 Proxy（如 MyCat、Vitess）或中间件（如 Alibaba PolarDB-X）的分片集群，扩容需提前设计分片键（如 user_id 取模），避免后期重分片。
- 小步快跑：先做读写分离，再考虑垂直拆分（按业务域拆库），最后水平分片
- 拒绝“一刀切分片”——订单、日志、配置类数据增长规律完全不同，应分类建模
- 所有节点统一规格（CPU/内存/磁盘类型），降低运维复杂度和容量误判风险
预留弹性与降级能力
集群不是越满越好。建议核心集群长期保持 CPU ≤60%、磁盘 ≤75%、连接数 ≤70%。同时必须定义降级策略：比如当从库延迟超 30 秒，自动切走报表类查询；当主库负载过高，关闭非关键审计日志或临时禁用低优先级定时任务。这些策略要写进预案，并定期演练。
- 用 sys schema 或 performance_schema 做实时容量画像，而非依赖 Zabbix 等通用监控
- 为每个集群配专属资源池（如独立物理机或 Kubernetes namespace），防止跨业务争抢
- 冷热数据分离：将 3 个月前订单归档到列存引擎（如 ClickHouse）或对象存储，主库只留热数据
持续验证容量模型
上线后每季度回溯：实际增长 vs 预估偏差是否在 ±15% 内？哪些指标最先触顶（是 IO 还是网络？是 buffer pool 不足还是锁等待？）。用 sysbench 模拟未来 6 个月的数据量和并发压测，验证扩容方案有效性。发现偏差就反向修正建模参数，比如把“平均每日新增行数”的系数从 1.2 调整为 1.5。
- 建立容量健康分（类似 SLO），包含延迟达标率、可用性、扩缩容耗时等维度
- 把容量决策纳入发布流程：任何新功能上线，必须附带《数据增长影响评估》
- 自动化容量预警：当某张表连续 3 天日增超阈值，自动触发 DBA 巡检工单
不复杂但容易忽略。容量规划不是一次性工作，而是嵌入研发、测试、运维全链路的常态化机制。
