本质
当业务的增长导致数据库瓶颈的时候，一种解决瓶颈的手段。分库分表的核心是创建一个对业务透明的逻辑大表，隔离存储的负载度，进而实现在业务应用眼里的无限存储！
分表
分表解决的是：过大的数据表影响计算速度的问题，比如单表上亿，那么拆成十个表，必然会比一个表更快，用了一部分计算落表时间，来换取单表计算的时间。
分库
分库更多解决的是机器局限的问题，单机容量有限，单机容量实际上是由机器硬件决定，比如网卡打满、CPU打满、机器磁盘写满等case，必须将计算分布到其他机器上解决。先拆分进程，随后将进程拆分到不同的机器上。
索引
对于数据库来说，强行提升了储存，而索引就是需要付出的代价。
当存储分布之后，单机的索引是无法满足对索引的要求，而SQL是对索引更上一层的封装，会有一定程度的限制，比如：分库分表最多能满足两个维度的拆分，Join表这种操作就变得异常困难。如何解决呢？方法就是，简单索引逻辑靠中间件构建虚拟索引，复杂索引靠其他方式构建外置索引。
所有的分库分表的中间件的工作，无非是在数据源和业务应用之间封装一层虚拟的满足基本需要的索引。业务应用发送请求到中间件，中间件起到一部分索引的作用，判定需要到哪个库，哪个表来执行，这其实就是单机数据库，选择表过程的外置。中间件还有一个作用是，对涉及逻辑表的部分，进行一部分SQL逻辑改写，来最终判定到某些部分执行。
对于更复杂的查询要求，应用方需要单独构建另外的索引，即把索引单独拆出来做成一个系统，来满足检索需要。作为代价来说，外置的索引会比内置的索引相对慢些，这是在系统架构上需要注意的地方。但是作为大原则，尽量把计算逻辑放置在索引外进行。
一致性
分库分表还好的地方在于，数据最终存储是一份的；
因为分库分表把需要操作的数据源分散了，操作的原子性在保障起来是有损耗了核心问题就在于，如何保障跨数据库、跨进程、跨机器的操作原子性。方法就是：外置保证一致性的方式
通过柔性分布式事务的方式来实现最终一致性，方式就是外置检查，某一动作失败时，往前回滚，不一定完全回滚数据状态，回滚到不影响发生其它业务逻辑的业务状态。
原文：https://www.cnblogs.com/iCanhua/p/15028405.html