保姆级教程 | 5个TiDB容量规划

▌ 技术引导
我是亲身经历过TiDB集群踩坑的，也做过多次容量规划的实战，最终总结出一套能落地、能复用、能防坑的方法。TiDB的容量规划不是简单的算公式，更像是一场对业务模式、数据增长、高并发场景的深度解构。我见过太多团队因为没提前规划，导致集群频繁扩容，磁盘爆满，CPU打满，甚至出现数据倾斜割裂。所以别再瞎猜了，用真实业务数据+预估增长率+最小平均负载去计算，比任何理论都靠谱。我用过的工具包括Prometheus+Grafana+TiUP+Ansible，也用过一些自研的监控脚本和数据模型。记住，TiDB不是MySQL，它的内存/磁盘/网络需求完全不一样，容灾、分区策略、复制因子这些参数要反复验证，不能照搬别人配置。别再随便搞个16核32G的机器去装TiDB了，那只是给扩容留了空间，根本解决不了真实问题。

▌ 技术参考

一 TiDB的容量规划必须基于实际业务数据和未来增长趋势，不能盲目照搬官方文档或他人配置。我曾经在某电商项目里因为低估了订单量增长速度，导致TiDB节点频繁出现内存溢出。解决方法是用Prometheus+Grafana监控过去3个月的QPS、慢查询、Prewrite耗时，然后按照业务拆分计算每个节点的平均负载。比如，假设单个TiDB节点处理1000QPS，配32G内存，那么在高负载时可能会出现严重延迟。建议采用分段式规划，先根据历史数据制定基准，再按年增长率做弹性预留。工具上推荐TiUP和TiDB Dashboard，这两个能直接显示内存、CPU、磁盘使用情况，避免自己写脚本分析数据的麻烦。

二 TiKV节点的规划要结合存储容量和读写性能。我亲测过，单TiKV节点的SSD容量如果低于100GB，就很容易出现磁盘写满导致集群不可用。计算方法是：总数据量×2.5倍冗余 = 每个TiKV节点的存储需求。这个2.5倍是基于Raft复制和数据分片的保守估计。同时要关注TiKV的写性能，比如单节点每秒能处理多少写入请求。如果业务是写多读少，建议至少用3个TiKV节点，因为TiDB的写入是分布式的，单节点负载过高会导致整体性能下降。部署时使用TiUP Cluster工具，配置--config参数指定集群拓扑，确保每个TiKV节点的磁盘和CPU资源匹配。

三 TiDB的内存规划不能只看官方推荐，必须结合实际查询类型和连接数。我之前用过一个金融系统，每个TiDB节点分配了64G内存，结果在高峰时段还是频繁出现OOM。后来发现是查询中存在大量JOIN操作，导致内存不够。解决方法是用TiDB Dashboard查看Top SQL和Memory Usage，然后根据这些数据调整内存配置。比如，如果某个节点的内存使用率长期超过70%，就要考虑增加节点或优化查询。内存参数配置时，重点关注tidb_query_max_mem_usage和tidb_query_mem_max_mb，这两个控制查询最大内存使用，设置不合理会直接拖垮集群。建议用TiUP进行配置，指定--config参数调整这些值。

四 分区策略是TiDB容量规划中容易被忽视但非常关键的部分。我曾经在一个日志分析系统里，因为没有合理分区导致某个TiDB节点的查询效率低下。TiDB的分区是基于range的，所以要根据数据分布和查询模式来设计。比如，如果业务按时间分区，可以使用时间戳作为分区键，这样在查询时能快速定位到特定分区，减少全表扫描。分区数量不宜过多，一般建议在100-200个之间，太多会导致元数据压力过大，影响调度效率。使用TiDB的CREATE TABLE语句时，必须明确指定分区策略，否则系统自动生成的分区可能不适用业务需求。

五 TiDB的副本配置直接影响容灾能力和写入性能。我见过有些团队为了省成本，把副本数设置成1，结果一旦某个TiKV节点故障，整个集群就瘫痪了。正确的做法是根据业务的SLA（服务等级协议）来设置副本数，比如高优先级业务建议使用3副本，低优先级业务可以使用2副本。同时，要确保每个副本的数据分布均匀，避免出现数据倾斜。使用TiUP部署集群时，配置topology参数，指定每个TiDB节点连接的TiKV副本数量。如果发现某个TiDB节点的副本负载不均，可以通过TiKV的split region命令手动平衡。

六 TiDB的网络带宽规划容易被忽略，但却是影响性能的关键因素。我用过一个直播平台，因为没有评估好TiDB和TiKV之间的通信流量，导致网络成为瓶颈。TiDB与TiKV之间的通信是基于raft协议的，每个region的写入和复制都会产生大量数据传输。建议使用高速网络，比如万兆口，或者将TiDB和TiKV部署在同一数据中心内，减少跨网络延迟。监控时用tcpdump抓包分析，看看每个节点的网络吞吐量是否达到瓶颈。如果发现网络流量过高，可以考虑增加TiKV节点或优化region数量。

七 评估存储性能时，不能只看磁盘容量，更要关注IOPS和吞吐量。我曾用过一块10TB的SSD，结果在高并发写入时出现严重延迟。原因在于SSD的IOPS不足以支撑业务需求。建议使用FIO工具测试存储设备的读写性能，特别是顺序写入和随机写入。TiKV的写入是基于LSM树的，所以存储设备的写入性能直接影响整个集群的吞吐。如果发现TiKV的write latency较高，可以考虑更换更高性能的存储设备，或者增加TiKV节点，提升整体写入能力。

八 TiDB的CPU规划要结合业务的计算密集型程度。如果业务是大量JOIN和聚合操作，TiDB节点的CPU需求会非常高。我之前在一个大数据分析项目中，误将TiDB节点的CPU设为8核，结果在高峰期CPU使用率高达95%。解决方法是用perf工具监控CPU使用情况，分析top命令中的具体进程。如果发现tidb_query和tidb_executor占用过高，就需要增加TiDB节点。CPU配置建议至少使用16核，如果业务是写多读少，推荐更高配置。部署时使用TiUP，配置--cpu参数，确保每个节点的CPU资源足够支撑业务负载。

九 TiDB的扩容和缩容要遵循一定的最佳实践，避免造成业务中断。我用过一个方法，就是通过TiUP的scale-in和scale-out命令进行渐进式扩容，这样可以减少对业务的影响。不过，缩容时要特别小心，因为TiDB的数据迁移和副本切换可能会导致延迟。建议在业务低峰期进行缩容，同时用TiDB Dashboard监控数据迁移进度。如果遇到数据迁移失败的情况，可以直接查看日志，检查是否由于配置错误或网络问题导致。要避免同时缩容多个节点，否则容易导致集群不稳定。

十 TiDB的监控工具必须用到，否则很难发现潜在问题。我常用Prometheus+Grafana来监控TiDB的各个指标，比如QPS、CPU、内存、磁盘使用率、网络吞吐量等。这些数据能帮助判断是否需要扩容或调整配置。另外，TiDB内置的Dashboard也非常好用，它能直接显示各节点的状态，比如Region分布、leader数量、副本状态等。监控过程中，重点关注TiDB的memory usage和region count，这两个指标直接反映集群是否负载过高。如果发现某个节点的region数量远高于其他节点，就需要调整TiKV的调度策略。

十一 TiKV的分片策略要根据业务模式进行动态调整。我见过一个例子，某个业务的数据量在某个时间段会突然激增，导致某个TiKV节点的region数量暴涨。这时候就需要用TiKV的split region命令手动拆分region，避免单节点负载过高。分片策略建议采用基于业务逻辑的键值范围，比如按用户ID或时间戳分片。这样查询时能快速定位到特定region，提高性能。使用TiUP部署时，配置topology参数，确保TiKV节点均匀分布region，避免出现数据倾斜。

十二 TiDB的读写分离策略要结合业务热点和查询模式。我曾经在一个社交平台项目中，把所有写操作放在TiDB，结果导致CPU和内存严重不足。后来调整为将部分高频写操作分发到某个专用TiDB节点，而其他写操作则使用TiKV的前置代理。读写分离的关键是使用TiDB的分布式读写能力，通过TiDB Dashboard查看各节点的读写负载，然后动态调整连接池配置。比如，如果某个节点的读请求过高，可以考虑增加TiDB节点或优化查询。

十三 TiDB的集群拓扑设计要遵循一定的原则，比如均衡负载、网络拓扑优化、容灾设计。我之前部署过一个3节点TiDB集群，结果因为网络延迟过高，导致了严重的读写延迟。后来将TiDB节点部署在同一数据中心内，并调整了副本的位置，确保每个TiKV节点都能均匀访问。拓扑设计时，要避免节点之间的网络瓶颈，同时确保每个TiDB节点能连接到所有TiKV节点。使用TiUP部署时，配置--config参数，确保拓扑结构合理。

十四 TiDB的备份和恢复策略要提前规划，尤其是数据量大的情况下。我用过一个工具，叫做TiDB Backup，它基于TiKV的快照机制，可以在业务低峰期进行全量备份。恢复时，建议使用TiDB Restore工具，配合TiUP进行集群恢复。备份策略必须包括定时任务和增量备份，同时要监控备份进度和成功率。如果备份失败，可以直接查看日志，分析是存储性能不足还是网络问题。恢复时，注意不要在高峰期进行，否则会影响业务可用性。

十五 TiDB的调度策略要根据业务优先级进行调整。我曾经在一个电商系统里，日志和订单数据优先级不同，所以将日志数据放在一个独立的TiKV集群里。这样既能保证订单数据的高可用性，也能避免日志数据影响其他业务。调度策略可以通过TiDB Dashboard进行调整，比如设置调度优先级或限制某些region的调度范围。使用TiUP时，配置--config参数，可以指定不同业务的数据分布策略，确保资源合理分配。如果发现某个TiKV节点频繁被调度，可能说明负载不均，需要调整分片策略或增加节点。