什么是分库分表？
分库分表是在海量数据下，由于单库、表数据量过大，导致数据库性能持续下降的问题，演变出的技术方案。
分库分表是由分库和分表这两个独立概念组成的，只不过通常分库与分表的操作会同时进行，以至于我们习惯性的将它们合在一起叫做分库分表。
通过一定的规则，将原本数据量大的数据库拆分成多个单独的数据库，将原本数据量大的表拆分成若干个数据表，使得单一的库、表性能达到最优的效果（响应速度快），以此提升整体数据库性能。
为什么要分库分表？
类似淘宝网这样的网站，海量数据的存储和访问成为了系统设计的瓶颈问题，日益增长的业务数据，无疑对数据库造成了相当大的负载。
随着规模的扩大，数据库面临如下问题：
- 读压力：并发 QPS、索引不合理、SQL 语句不合理、锁粒度;
- 写压力：并发 QPS、事务、锁粒度;
- 物理性能：磁盘瓶颈、CPU 瓶颈、内存瓶颈、IO 瓶颈、事务数、连接数等总是有限；
- 数据量太大：数据规模达到几千万行，数据库索引树庞大，查询性能出现瓶颈；
- 可用性低：如果是单库数据库宕机会导致 100%服务不可用，N 库则可以将影响面降低 N 倍；
最终数据库的数据处理能力都将遭遇瓶颈，所以分表分库就可以排上用场了，当然出之外还有缓存等一系列优化手段都可以采用。
分库分表带来的问题？
1.事务性问题
- 方案一：在进行分库分表方案设计过程中，从业务角度出发，尽可能保证一个事务所操作的表分布在一个库中，从而实现数据库层面的事务保证。
- 方案二：方式一无法实现的情况下，业务层引入分布式事务组件保证事务性，如事务性消息、TCC、Seata 等分布式事务方式实现数据最终一致性。
- 分库可能导致执行一次事务所需的数据分布在不同服务器上，数据库层面无法实现事务性操作，需要更上层业务引入分布式事务操作，难免会给业务带来一定复杂性，那么要想解决事务性问题一般有两种手段：
2.主键自增 ID唯一性问题
- 在数据库表设计时，经常会使用自增 ID 作为数据主键，这就导致后续在迁库迁表、或者分库分表操作时，会因为主键的变化或者主键不唯一产生冲突，要解决主键不唯一问题，有如下方案：
- 方案一：自增 ID 做主键时，设置自增步长，采用等差数列递增，避免各个库表的主键冲突。但是这个方案仍然无法解决迁库迁表、以及分库分表扩容导致主键 ID 变化问题
- 方案二：主键采用全局统一 ID 生成机制：如 UUID、雪花算法、数据库号段等方式。
3.跨库多表 join 问题
首先来自大厂 DBA 的建议是，线上服务尽可能不要有表的 join 操作，join 操作往往会给后续的分库分表操作带来各种问题，可能导致数据的死锁。可以采用多次查询业务层进行数据组装(需要考虑业务上多次查询的事务性的容忍度)
4.跨库聚合查询问题
分库分表会导致常规聚合查询操作，如 group by，order by 等变的异常复杂，需要复杂的业务代码才能实现上述业务逻辑。
如何分库分表？
1.垂直拆分
垂直拆分又可以分为：垂直拆表和垂直拆库。
1)垂直拆表
即大表拆小表，将一张表中数据不同”字段“分拆到多张表中，比如商品库将商品基本信息、商品库存、卖家信息等分拆到不同库表中。
2)垂直拆库
垂直拆库则在垂直拆表的基础上，将一个系统中的不同业务场景进行拆分，比如把一个数据库拆分为：商品数据库、用户数据库、交易数据库。
如下图所示：
2.水平拆分
前边说了垂直切分还是会存在单库、表数据量过大的问题，当我们的应用已经无法在细粒度的垂直切分时， 依旧存在单库读写、存储性能瓶颈，这时就要配合水平切分一起了，水平切分能大幅提升数据库性能。
这里的水平拆分又可以分为：水平拆表和水平拆库。
1)水平拆表
将数据按照某种维度拆分为多张表，但是由于多张表还是从属于一个库，其降低锁粒度，一定程度提升查询性能，但是仍然会有 IO 性能瓶颈。
2)水平拆库
将数据按照某种维度分拆到多个库中，降低单机单库的压力，提升读写性能。
分库分表中间件有哪些
常用的分库分表中间件，如下图所示：
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》