海量数据写入——万级并发的订单系统如何分库？

一定要分表分库吗？

当然不一定。

虽然很多互联网公司的体量很大、用户非常多，但你千万不要被这些现象迷惑了。实际上，90% 以上的系统能够发展到上百万、上千万数据量已经很不错了。对于千万的数据量，开源的 MySQL 都可以很好地应对，更别说一些商业数据库了。

另外，当数据增长到一定量级后，可以在业务层面做一些处理。比如根据业务特点，对无效数据、软删除数据，以及业务上不会再查询的数据进行统一归档，这也是一个成本低、效果明显的方式了。

一定要分库吗？

说到分库，他当然能够解决存储的问题，假设原先单库只能最多存储2千万的数据量。采用分库之后，存储架构变成下图所示的分库架构，每个分库都可以存储2千万数据量，容量的上限一下提升了。

虽然容量提升了，但也带来了很多其他问题。

• 分库数据间的数据无法再通过数据库直接查询了，比如跨多个分库的数据需要多次查询或借助其他存储进行聚合再查询。
• 分库越多，出现问题的可能性越大，维护成本也变得更高。
• 无法保障跨库间事务，只能借助其他中间件实现最终一致性。

所以在解决容量问题上，可以根据业务场景选择，不要一上来就要考虑分库，分表也是一种选择。

分表是指所有的数据均存在同一个数据库实例中，只是将原先的一张大表按一定规则，划分成多张行数较少的