TiDB 分布式数据库实战指南

当单机 MySQL 顶不住的时候

当单实例数据库逼近容量或连接数上限，第一反应往往是分库分表。但分库分表带来的路由维护、跨库事务和连续重构成本，会让团队在每次业务增长时都重新付出代价。

这个技能面向被单机容量与扩展焦虑困扰的架构师，帮你判断何时应当转向「能水平加机器」的数据库，而不是反复在应用层做拆分。

技能如何帮你做选型与落地

核心方法是一个 四步决策路径，从评估到上线逐层降低风险：

1. 评估契合度：先判断读写模式是否以简单 KV 或 SQL 为主，业务能否接受短暂一致性窗口，以及是否真的到达了扩展拐点——避免在数据量尚小时过早引入分布式复杂度。
2. 兼容迁移：利用 TiDB 兼容 MySQL 协议这一事实，先迁移读流量进行验证，确认无异常后再切换写流量。这样业务代码改动量被控制在最小范围。
3. 容量规划：理解 Region、存储节点与计算节点可以分别扩展，并关注 PD 调度策略和副本放置，做到按瓶颈精准扩容而非盲目堆机器。
4. 混合负载：把实时分析与事务放在同一技术栈，省去独立 ETL 管道的数据搬运；在 AI 或智能体场景下，还可以叠加向量检索能力，让事务与语义检索在同一引擎内完成。

技能还内置了 常见陷阱清单，比如单行或单 Region 热点会拖垮整体吞吐、需要合理设计主键避免递增热点、重分析查询必须用资源组隔离以免影响在线事务。

适用边界与注意点

这个技能提供的是选型判断与运维方法论，不是一键部署的魔法。如果数据量尚小就上分布式，运维成本往往高于收益，这是最典型的「小业务上重架构」错误。

涉及生产变更时，请在隔离环境中完成演练，准备好回滚方案，并以 TiDB 官方文档和架构评审结论为最终口径。AI 输出的建议仅作为决策参考，不能替代经过验证的官方操作流程。