一张订单表，上线时百万级数据量，查询响应毫秒级。两年后数据涨到几亿条，同样的查询开始频繁超时。DBA 加了索引，短期有效；数据继续涨，索引本身也变成了性能负担。加字段？DDL 变更需要在数亿行数据上执行，锁表风险让人不敢轻举妄动。
这不是某个团队的个别经历，而是很多企业在业务增长过程中都会面对的问题：单表数据量过大，整个数据库的性能和运维都会被拖入泥潭。
单表过大，到底在拖累什么？
当一张表的数据从百万级增长到亿级甚至更高，问题远不止"查询变慢"这一条。
查询性能持续恶化。 数据量大意味着索引树的层级更深、扫描范围更广。一条原本能通过索引快速定位的查询，在数据量暴增后可能需要扫描大量索引页，响应时间从毫秒级攀升到秒级。如果查询涉及多列筛选或范围查询，情况更加严重——优化器可能放弃索引，直接全表扫描。
索引维护成本越来越高。 为了维持查询性能，DBA 会不断增加索引。但每多一个索引，数据写入时就需要同步更新多棵 B+ 树。当数据量达到亿级，一次 INSERT 操作可能需要更新多个索引，写入延迟和锁竞争都会显著增加。索引本身的存储空间也在持续膨胀，进一步加大磁盘 I/O 压力。
DDL 变成高风险操作。 在亿级行的表上加字段、改类型、加索引，传统数据库通常需要长时间锁表或全表重建。对于 7×24 在线的业务来说，这种操作的窗口几乎不存在。一些数据库提供了 online DDL 能力，但在大表上执行时资源消耗巨大，仍然可能影响在线业务的稳定性。
备份恢复时间直线上升。 数据量越大，全量备份耗时越长，恢复时间也随之增加。当单表达到数亿行，一次全量备份可能需要数小时，而在故障场景下恢复耗时更是不可控。备份窗口不够、恢复时间超出业务容忍范围，这些都是非常现实的风险。
这些问题叠加在一起，指向一个核心矛盾：单张表的数据量已经超出了单体数据库能够高效管理的范围。接下来要做的是一个决策——是拆这张表，还是换一个能扛住大表的架构？
方案一：分表——把大表拆小
分表是解决单表过大的传统思路，核心做法是把一张大表拆成多张小表，每张表只存一部分数据。
水平分表：按行拆分
水平分表是最常见的做法。比如一张订单表按用户 ID 取模，拆成 16 张结构相同的子表，每张表只存一部分用户的数据。查询时，应用层根据分片规则路由到对应的子表。
优点： 每张子表的数据量和索引量都控制在较小范围内，查询性能和写入性能都能得到明显改善。
代价： 跨表查询变得复杂。如果业务需要查询"某个时间范围内所有用户的订单汇总"，就不得不扫描所有子表再合并结果。此外，分片规则一旦确定就很难调整——如果业务增长导致某张子表再次膨胀，重新分片的难度和风险都很高。
垂直分表：按字段拆分
垂直分表是把一张宽表中的字段拆分到多张表中。比如订单的主信息（订单号、用户 ID、金额、时间）放在一张表，扩展信息（备注、附件、日志）放在另一张表，通过主键关联。
优点： 主表保持精简，查询核心字段时 I/O 量更小，缓存效率更高。
代价： 如果业务经常需要同时访问主表和扩展表的字段，就会产生大量关联查询，增加了应用层的复杂度。而且垂直分表对"行数过多"的问题帮助有限——如果表里的行数本身是瓶颈，拆字段并不能缓解。
分表适合什么情况？
分表更适合以下场景：业务查询模式相对固定，大部分查询可以通过某个明确的字段（如用户 ID、时间）路由到单张子表；数据量的增长趋势基本可预测，初始分片数可以覆盖较长时间；团队能够接受和承接分表带来的开发与运维复杂度。
反过来，如果业务查询模式多样、经常需要跨表聚合、分片规则可能需要调整，分表后的问题可能比拆之前更棘手。
方案二：升级架构——迁移到分布式数据库
另一种思路是：不拆表，而是换一个能扛住大表的数据库。
分布式数据库在底层自动将数据分散到多个存储节点上，对应用层来说，看到的是一张逻辑上的"大表"，但底层数据已经在多台机器上分布存储和并行处理。
这意味着单表数据量从百万涨到亿级甚至十亿级，应用层面几乎不需要做任何改造。查询可以在多个节点上并行执行，写入也因数据分布在不同分区而获得并行处理能力，性能不会因为数据量增长而线性下降。
适合什么情况？ 数据量持续增长且增长趋势难以预测；业务查询场景多样，不适合用单一分片键拆分；希望避免分表带来的开发和运维复杂度；系统需要在线扩展能力，不能因为扩容而停机。
需要权衡的点： 迁移到分布式数据库意味着一次架构层面的变更，前期需要投入评估和测试时间。不同分布式数据库对大单表的支持程度、自动分片策略、应用适配要求都有差异，选型时需要重点关注。不过，一些成熟的分布式数据库已经能做到对应用透明——表的定义方式和查询语法与传统数据库基本一致，迁移成本相对可控。
比如，平凯数据库、TiDB 等分布式数据库天然支持大单表场景，底层自动完成数据分片和分布，对上层应用几乎完全透明。对于正被单表膨胀困扰的团队来说，这是一种不需要"拆"就能解决问题的思路。
一个简单的判断
分表还是升级架构，没有绝对的对错，取决于团队的具体情况。可以用几个问题来辅助判断：
- 查询模式是否固定？ 如果大部分查询都能通过一个明确的字段路由到单表，分表是可行的。如果查询经常涉及多维度筛选、聚合统计，分表会让查询变得更复杂。
- 分片规则是否稳定？ 如果业务增长可能导致分片不均匀或需要重新分片，分表的后遗症会比较严重。
- 团队能承接分表的复杂度吗？ 分表后，开发、测试、运维的工作量都会增加。如果团队资源有限，维护多张子表的长期成本可能超出预期。
- 数据增长是否可预测？ 如果数据增长趋势明确、总量有天花板，分表可能就够了。如果增长持续且不可预测，分布式数据库的弹性扩展更从容。
一个粗略的判断标准是：当单表数据量达到数千万级别且仍在快速增长，同时业务查询复杂度较高、团队不想引入分表的维护负担，这时候认真评估分布式数据库是值得的。反之，如果数据量问题可以通过简单的水平分表解决，且分片规则长期稳定，分表仍然是一个轻量且经过验证的选择。
最后一点建议：无论走哪条路，都不要等到单表膨胀到严重拖垮业务再做决策。提前评估、提前测试、提前准备迁移方案，比在凌晨被告警惊醒后仓促应对要靠谱得多。