先给一个反直觉的结论：判断"该不该上 分布式 **"，没有一个放之四海而皆准的数字。**500 万行、2000 万行、1 亿行、2GB、200GB——这些阈值经常被引用，但真正可靠的判断标准只有一个：常规优化手段是否已经全部失效。
很多人拿着某篇博客里的数字对照自己的表，发现"还没到 500 万行，不用管"，结果半年后一次大促直接把库打崩。也有人把几十万行的表强行拆了库，业务代码改了一个季度，性能反而更差。规模判断需要从多个维度综合看，而不是盯着单一指标。
先分清三个维度：数据量、性能、运维
数据量维度：不只看总量，还要看增长速度和单行大小。
-
单表行数：工程经验上，单表 5000 万行以内通常可控；行数过亿后，B+ 树层级加深、查询和 DDL 都会明显变慢。有头部电商团队的经验是在单表 5000 万行以内就切分。
-
单表容量：单表超过 200GB 时，备份恢复会非常困难，全量备份时间可能超过业务容忍窗口。
-
增长速度：每月新增百万级记录的表，是分表/升级的高优先级候选；增长平缓的大表反而不急。
性能维度：写入、连接数、延迟是三个关键信号。
-
写入 QPS：单库写入能力有硬上限，有团队压测的参考值是单库写 QPS 在 3000-4000 左右就需要考虑拆分；写入压力突破上限时，大量请求会拥堵在单库，轻则超时重试，重则影响数据一致性。
-
连接数：单实例连接数有限，当多个业务模块共用一个库、连接池把连接占满时，表现为"什么 SQL 都慢"，这是分库（而不是分表）的信号。
-
延迟：简单查询耗时超过 1 秒、ALTER TABLE 等 DDL 耗时过长，说明当前架构已经吃紧。
运维维度：这个维度最容易被忽略，却往往最先逼你做决定。备份窗口拉长、主从延迟严重、慢查询日志里堆满大表扫描——这些是"数据量已超承载"的间接证据。
关键判断：常规优化是否已用尽
在谈分布式之前，先确认以下手段是否真的试过：索引优化与 SQL 重写、读写分离、缓存（Redis 等）、分区表、冷热数据归档。绝大多数"变慢"问题在这一层就能解决。只有当这些手段都试过、瓶颈依然存在时，才值得进入架构级改造。
这也是为什么分布式不是"数据到了某个规模就自动触发"——它解决的是"常规手段解决不了的问题"，而不是数据量本身。
分库分表，还是分布式数据库？
确定要升级后，还有第二条分岔路。分库分表适合：业务有明确的分片键、单条业务线增长、团队有中间件运维经验、业务能接受最终一致性与跨库查询的复杂度。分布式数据库（以 TiDB 为例）适合：写入持续扩展、数据量看不到天花板、多个业务模块耦合在同一套数据里、需要在线弹性扩缩容、对高可用和强一致有硬要求。
一个简单的判断方法：如果团队把大量精力花在分片路由、 分布式 事务、跨库查询这些"与业务无关"的问题上，那大概率选错了方向。分布式数据库的价值，正是把这些复杂度从业务代码里拿出来，交给系统本身。
什么时候开始考虑：提前量比阈值更重要
分布式改造从来不是一蹴而就，从评估、验证到迁移上线通常以季度计。因此更务实的做法是：当数据增长曲线显示未来 6-12 个月会触达上述任一维度的承载上限，且常规优化已用尽时，就启动评估。**提前规划，可以让你从容地做兼容性验证和灰度迁移；等到线上告警连环响才动手，就只能接受停机窗口和迁移风险。
总结来说：规模判断看"数据量 + 性能 + 运维"三个维度，触发条件看"常规优化失效"，行动时机看"未来 6-12 个月的增长曲线"。