1：为什么数据库要分库分表

1：为什么要分库分表

业务快速发展，单数据库出现性能瓶颈的时候，要将数据进行切分。将原来在一台数据库上的数据，分散到多台数据库中，降低单体数据库负载

2：数据切分类型

1：垂直切分

垂直切分是将多个业务模块拆分到多个数据库中，也就是将原有单个数据库的表根据业务模块放入多个数据库中。

比如，订单表和商品表在同一个数据库中，而现在我们要对其进行切分，使得订单表和商品表分别落在不同的物理机中的不同数据库中，使其完全隔离，从而达到降低数据库负载的效果。如图所示：

优点：

• 拆分后业务清晰，拆分规则明确
• 系统之间容易扩展和整合
• 数据维护简单

缺点：

• 部分业务表无法 join，多表关联查询。只能通过接口调用，提升了系统的复杂度
• 跨数据库事务难以处理
• 垂直切分后，某些数据过于庞大，仍然存在单体性能瓶颈

2：水平切分

水平切分是将原有一张表根据规律划分成多张表

水平拆分相比垂直拆分，更为复杂。它需要将一个表中的数据，根据某种规则拆分到不同的数据库中，例如：订单尾号为奇数的订单放在订单数据库1中，而订单尾号为偶数的订单放在了订单数据库2中。这样原本存在于一个数据库中的数据，被水平的切分为了两个数据库。在查询订单数据时，我们还要根据订单的尾号，判断这个订单在数据库1中，还是在数据库2中，然后将这条SQL语句发送到正确的证据库分钟，查出订单。水平切分的架构图如下：

 水平拆分数据，要先订单拆分的规则，找到你要按哪个维度去拆分，还是前面订单的例子，我们按照订单尾号的奇偶数去拆分，那么这样拆分会有什么影响呢？假如我是一个用户，我下了两个订单，一个订单尾号为奇数，一个订单尾号为偶数，这时，我去个人中心，订单列表页去查看我的订单。那么这个订单列表页要去怎么查询，要根据我的用户id分别取出订单1库和订单2库去查询出订单，然后再合并成一个列表，是不是很麻烦。所以，咱们在拆分数据时，一定要结合业务，选择出适合当前业务场景的拆分规则。那么按照用户id去拆分数据就合理吗？也不一定，比如：咱们的身份变了，不是买家了，而是卖家，我这个卖家有很多的订单，卖家的后台系统也有订单列表页面，那这个订单列表页要怎么样去查？是不是也要在所有的订单库中查一遍，然后再聚合成一个订单列表呀。那这样看，是不是按照用户id去拆分订单又不合理了

有几种水平拆分的典型分片规则：

• 用户id求模，我们前面已经提到过
• 按照日期去拆分数据
• 按照其他字段求模，去拆分数据

 上图是按照用户id去求模拆分的一个示意图

优点：

• 解决了单库大数据、高并发的性能瓶颈
• 拆分规则封装好，对应用端几乎透明，开发人员无需关系拆分细节
• 提高了系统的稳定性和负载能力

缺点：

• 拆分规则很难抽象化
• 分片事务一致性难以解决
• 二次扩展时，数据迁移、维护难度大。比如：开始我们按照用户id对2求模，但是随着业务的增长，2台数据库难以支撑，还是继续拆分为4个数据库，那么这时就需要做数据迁移了

3：数据切分遇到的共同缺点

无论是垂直切分，还是水平切分，它们解决了海量数据的存储和访问性能问题，但也随之而来的带来了很多新问题，它们的共同缺点有：

• 分布式的事务问题
• 跨库 join 问题
• 多数据源的管理问题

针对多数据源的管理问题，主要有两种思路：

1. 客户端模式，在每个应用模块内，配置自己需要的数据源，直接访问数据库，在各模块内完成数据的整合
2. 中间代理模式，中间代理统一管理所有的数据源，数据库层对开发人员完整透明，开发人员无需关注拆分的细节

4：成熟的解决方案

基于这两种数据切分模式，目前都有成熟的第三方软件，接下来在我们的视频中，会分别给大家介绍这两种模式的代表作：

• 中间代理模式：MyCat
• 客户端模式：sharding-jdbc