容量规划需动态对齐业务增长、数据规律与硬件边界，涵盖存储节点数计算、冷热分离、余量预留、Proxy与Set扩缩容、全局组件冗余及滚动评估机制。

容量规划不是算完分片数就结束的事，而是要让存储和计算资源在业务增长周期内始终“够用但不浪费”。关键在于把未来数据量、访问压力、硬件能力这三者串起来看，而不是孤立地定库表数量。

先看存储增长：从数据总量倒推单节点容量上限

存储扩容的核心逻辑是：总数据量 ÷ 单节点可承载数据量 = 最少需要的存储节点数。但这个“单节点可承载量”不能拍脑袋定。

• 单表行数建议控制在500万–2000万之间，具体取值必须基于压测——比如在SSD+16GB内存的MySQL实例上，1000万行带合理索引的订单表，查询延迟稳定在20ms以内，那就可以锚定为1000万/表
• 要考虑冷热分离。例如近3个月订单高频查询，老数据只归档不查，那实际活跃数据可能只占总量30%，存储节点可以按活跃数据配，归档数据走低成本对象存储
• 预留20%–30%空间余量，用于索引膨胀、临时排序、binlog缓冲等隐性开销，别把磁盘用到90%才告警

再看计算增长：按QPS和连接数反推Proxy与存储节点规模

计算资源瓶颈往往比存储来得更早，尤其是跨分片查询增多、事务协调变重之后。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• Proxy层（计算平面）要扛住所有SQL入口流量。单个Proxy节点建议CPU使用率长期低于60%，连接数不超过3000，否则路由延迟会明显上升。若预估峰值QPS为1.5万，单Proxy实测支撑4000 QPS，则至少需4个Proxy节点，并做负载均衡
• 存储节点（Set）不仅要存数据，还要处理本地事务、强同步复制、本地索引维护。一个Set（一主两备）在高写入场景下，主节点CPU常驻75%以上就该预警，此时不是加备库，而是考虑拆分出新Set
• 别忽略全局协调组件（如TDSQL的调度平面）。它虽不存业务数据，但元数据变更、分布式事务两阶段提交都依赖它。三节点部署是底线，五节点更适合中大型集群，避免脑裂风险

最后做动态校准：把时间维度加进去，别只看静态数字

业务不是静止的，容量也不能一次规划管五年。真正有效的做法是建立滚动评估机制。

• 以月为单位跟踪两个核心指标：单分片日均新增行数、单分片P95查询延迟。如果连续两个月前者增速超预期15%，后者上升超20%，就触发扩容预研
• 对增长趋势建模。例如订单表当前1亿行、日增500万，按指数拟合未来18个月曲线，再叠加促销季脉冲系数（如双11期间日增翻倍），得出各时间节点的存储与QPS峰值
• 每次版本上线前做一次轻量级压测：用生产流量镜像打新分片结构，验证Proxy转发、跨分片JOIN、分布式事务提交耗时是否仍在SLA内

本质上，容量规划是业务节奏、数据规律和硬件边界的三方对齐。算得准不如跟得紧，静态公式只是起点，持续观测和小步快调才是落地关键。