订单表增长到千万甚至上亿行后，查询变慢并不意味着必须马上分库分表。索引、SQL、归档和硬件配置仍应先排查；只有当单表规模、写入压力和查询延迟同时达到业务瓶颈，水平拆分才值得进入方案评审。
本文从决策顺序出发，梳理垂直拆分与水平拆分的区别，并重点说明分片键、分片算法、全局 ID、跨分片查询和扩容设计。内容适合正在评估 MySQL 分片、中间件或分布式数据库的开发者和小团队。
先判断：问题是数据量，还是访问方式
“表很大”不是充分条件。先检查慢查询日志和执行计划，确认是否存在缺失索引、低选择性索引、隐式类型转换、返回列过多或不必要的全表扫描；再评估历史数据归档、冷热分离、读写分离和实例规格调整能否解决问题。
分库分表会把单机数据库问题变成分布式系统问题。SQL 路由、事务、ID、备份恢复、监控和数据迁移都需要重新设计。建议把下面几项作为进入评审的信号，而不是使用固定的行数阈值：
- 索引和 SQL 优化后，核心查询仍无法满足延迟目标；
- 写入、连接数、磁盘 I/O 或存储容量接近实例上限；
- 归档历史数据后，活跃数据仍持续增长；
- 业务已经能明确未来一段时间的访问模式和容量增长。
行数阈值只能作为预警，不能脱离字段宽度、索引数量、查询模式和硬件配置单独判断。
垂直拆分与水平拆分怎么选
垂直拆分按字段或业务边界拆解。例如把订单主信息、明细和低频扩展字段分开，或将订单、商品、用户拆到不同服务和数据库。它适合解决宽表、字段访问冷热不均和业务边界混杂的问题，但不会直接消除同一业务表的行数增长。
水平拆分保留相同的表结构，把数据行按规则分到多个逻辑表或数据库节点。例如按 user_id 计算分片号：
shard = hash(user_id) % 128
orders_0000 ... orders_0127它适合单表容量、写入吞吐或单实例资源成为瓶颈的场景。代价是一次查询可能要访问多个分片，跨分片排序、聚合、连接和事务也更复杂。实际项目中，垂直拆分和水平拆分可以组合，但每增加一层拆分，都应说明它解决的具体瓶颈。
分片键决定了查询成本
分片键需要同时满足两个条件：尽量均匀地分布数据，并覆盖高频查询的定位条件。以订单表为例，如果最常见的请求是“查询某个用户的订单”，user_id 往往比地区、状态等字段更适合作为候选键。地区可能造成数据倾斜，状态则可能把大量数据集中到少数分片。
分片前应先整理查询清单，至少回答：
- 读写比例和最高频接口是什么？
- 查询是否总能带上候选分片键？
- 报表是否需要按时间、商户或状态跨用户聚合？
- 是否存在必须按订单号、外部业务号反查的场景？
如果按订单号查询却没有订单号分片键，路由层可能只能广播到全部分片。常见做法是建立按业务号定位的冗余索引表，或者接受跨分片查询并限制扫描范围；不能只依赖“分片后单表变小”来解决路由问题。
还要提前评估数据倾斜。均匀的哈希并不等于访问均匀，某些大客户或热点用户仍可能形成热点分片。必要时可将大客户单独路由，或为热点数据设计缓存和限流策略。
分片算法与扩容要一起设计
哈希取模实现简单，适合分片数量稳定、键分布较均匀的系统，但直接从 128 片改为 256 片会改变大量键的映射，迁移和双写切换需要完整方案。范围分片便于按时间或 ID 区间管理，适合冷热数据和范围查询，但要防止新数据集中写入当前区间。一致性哈希可以减少扩容时受影响的数据范围，但需要虚拟节点、迁移和负载均衡机制，复杂度更高。
不要把“先拆成 128 片”当成扩容设计。更稳妥的做法是提前确定逻辑分片数与物理节点的映射，或使用支持在线迁移的路由层，明确数据校验、限流、回滚和双写窗口。扩容演练应覆盖历史数据、增量写入、失败重试和切换后的读流量。
拆分后必须补齐的基础设施
全局 ID
各分片独立自增会产生重复 ID。可评估号段、雪花类算法或数据库服务生成的全局 ID，并确认时钟回拨、号段耗尽、服务不可用和排序需求。ID 方案不仅要保证唯一，还要考虑索引大小、写入局部性和跨系统传递。
跨分片查询
ORDER BY、GROUP BY、分页和 JOIN 可能需要多个分片返回数据后再合并。深分页尤其容易放大扫描量。应优先让接口带分片键，采用游标分页，按时间或范围限制扫描，并把面向报表的查询同步到分析库或汇总表，而不是让交易库承担任意跨片分析。
事务与一致性
跨分片写入不能继续假设本地事务可以覆盖所有参与者。可以重新设计聚合边界，减少跨片事务；必须跨片时，再根据一致性要求评估可靠消息、补偿流程或分布式事务协议。无论选择哪种方案，都要提供幂等键、状态机、重试和对账机制。
运维与数据迁移
分片数量增加后，备份恢复、DDL、监控、容量告警和故障演练都会变成批量操作。迁移前应建立源端与目标端的数据校验，控制复制延迟和限流，准备回滚路径。中间件可以统一路由，但不能替团队消除这些运维责任；数据库内核集成的分布式能力也需要结合产品边界、兼容性和团队经验评估。
一份可执行的决策清单
- 能否通过索引、SQL、归档或规格调整解决？能解决就先不拆。
- 拆分目标是宽表问题、单表容量问题，还是写入吞吐问题？目标不同，方案不同。
- 最重要的查询能否带上分片键？不能就先设计索引表、汇总表或替代查询路径。
- 全局 ID、跨片事务、报表、备份恢复和扩容是否已有负责人和演练计划？
- 是否有明确的容量模型、迁移窗口、监控指标和回滚方案？
结语
分库分表不是“把一张表复制成很多张表”这么简单，而是一次数据访问模型改造。它可以缓解单实例的容量和吞吐压力，却会引入路由、迁移、一致性和运维成本。对个人站长和小团队而言，优先把查询、索引、归档和实例规格做好；对确实进入容量瓶颈的系统，则应从查询模式和扩容路径倒推分片设计，再决定使用中间件还是具备分布式能力的数据库产品。