分库分表支持海量数据

是否真的要分库？

容量提升了，但也带来了很多其他问题。比如：

1. 分库数据间的数据无法再通过数据库直接查询了。比如跨多个分库的数据需要多次查询或借助其他存储进行聚合再查询。

2. 分库越多，出现问题的可能性越大，维护成本也变得更高。

3. 无法保障跨库间事务，只能借助其他中间件实现最终一致性

分表后的子表仍在原有库中，而分库则是子表移动到新的数据库实例里并在物理上单独部署。

分表除了能解决容量问题，还能在一定程度上解决分库所带来的三个问题。

1. 分表后可以通过 join 等完成一些富查询，相比分库简单得多。

2. 分表的数据仍存储在一个数据库里，不会出现很多分库。无须引入一些分库中间件，因此维护成本和开发成本均较低。

3. 因为在同一个数据库里，也可以很好地解决事务问题。

如何实现分库？

不同的分库维度决定了部分查询是否能直接使用数据库，以及是否存在数据倾斜的问题。

直接满足最重要的业务场景划分。在业务上，所有的订单数据都是隶属于某一个用户的。在选择分库维度时，可以按订单归属的用户这个字段进行分库。按此维度分库后，同一个用户的订单都在某一个分库里。

在确定分库字段时应该以直接满足最重要的业务场景为准

订单模块最重要的功能是什么？

答案是保证客户（即买家）的各项订单功能能够正常使用，比如下单、下单后立刻（无延迟）查看已购的订单信息、待支付、待发货、待配送的订单列表等。

对于倾斜的问题，可以采用最细粒度的拆分，即按数据的唯一标示进行拆分，对于订单来说唯一标示即为订单号。采用订单号进行分库之后，用户的订单会按 Hash 随机均匀地分散到某一个分库里。这样就解决了某一个分库数据不均匀的问题。

在架构中，没有一种方案可以解决所有问题的，更多的是根据场景去选择更适合自己的方案。

分库中间件选择

整体上各类分库中间件可以分为两大类：一种是代理式、另外一种是内嵌式。

不断进行分库分表一定能解决容量问题，但“杀敌一千，自损八百”的事情少做为宜。使用分库分表会将代码和架构的复杂度变高，带来资源成本上升等问题。另外，在使用系统时，用户（不管是客户还是管理员）的查询体验也存在一定的降级。

在使用分库分表前，你需要确定这是否是最优选择，是否能通过其他更简单的手段处理无效数据清理？架构是通过最小代价解决问题，而不是技术工具的比拼。