数据库 分表分库

一、分表分库
　　1、垂直分区：
　　　　根据数据库里面数据表的相关性进行拆分。 例如，用户表中既有用户的登录信息又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。
　　　　简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。

　　垂直拆分的优点：

　　　　可以使得行数据变小，在查询时减少读取的Block数，减少I/O次数。

　　　　此外，垂直分区可以简化表的结构，易于维护。
　　垂直拆分的缺点：

　　　　主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。

　　　　此外，垂直分区会让事务变得更加复杂水平拆分最好分库 。

　　水平拆分

　　　　水平拆分能够 支持非常大的数据量存储，应用端改造也少，但 分片事务难以解决 ，跨界点Join性能较差，逻辑复杂。
《Java工程师修炼之道》的作者推荐 尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度 ，一般的数据表在优化得当的情况下支撑千
万以下的数据量是没有太大问题的。

　　　　如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中间件的网络I/O。

　　水平分表：
　　　　表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询次数
　　适用场景
　　　　1、表中的数据本身就有独立性，例如表中分表记录各个地区的数据或者不同时期的数据，特别是有些数据常用，有些不常用。
　　　　2、需要把数据存放在多个介质上。
　　水平切分的缺点
　　　　1、给应用增加复杂度，通常查询时需要多个表名，查询所有数据都需UNION操作
　　　　2、在许多数据库应用中，这种复杂度会超过它带来的
　　优点，查询时会增加读一个索引层的磁盘次数

二、分库分表后面临的问题
　　事务支持 分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
　　跨库join
　　　　只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
　　分库分表方案产品
　　　　跨节点的count,order by,group by以及聚合函数问题 这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。数据迁移，容量规划，扩容等问题 来自淘宝综合业务平台团队，它利
用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。
　　ID问题
　　　　一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由. 一些常见的主键生成策略