mysql & 分库分表

分库分表

单表中出现了百万甚至千万级别的数据，增删改查的开销也会越来越大，加上物理服务器资源有限，最终数据库承载的数据量和数据处理能力都将遇到瓶颈。

分库分表的设计，目的为了缓解数据库的压力，最大限度提高数据操作的效率。

数据分表：

    单表的数据量过大，操作表的时候就会加大系统的开销，每次查询会消耗数据库大量资源，多表联合查询情况下，这种劣势更加明显，mysql对插入数据的时候 会对表进行锁表操作，表锁定或者行锁定。无论哪种方式，都意味着前面一条数据操作表或者行的时候，后面的请求都在排队，访问量增加的时候都会影响数据库的效率。

一般来说 mysql数据库单表记录最好控制在500万条。

垂直分表：

    根据业务把一个表中的字段（field）分到不同的表中；这些被分出去的业务通常根据业务需要，例如一些不常用的字段，一些长度较长的字段。

 一般被拆分的表的字段比较多，主要避免查询的时候出现因为数据量大而造成的跨页问题。

水平分表：

    将一个表中的数据，按照关键字（id）对一个具体的数字取模，得到的余数就是需要存放到的新表的位置。

分库

每一个物理数据库支持数据都是有限的，每一次的数据库请求都会产生一次数据库连接，当一个库无法支持更多访问时，把原来的单个库分成多个，帮助分担压力。

可以根据具体场景进行划分：业务不同分库 ，根据冷热数据进行分库，数据访问频率，根据访问数据的地域和时间范围进行划分。

分布式事务原理：

    有时候业务代码可能会同时访问两个不同的数据库，做不同的操作，同时这两个操作有可能放在同一个事务中处理。

这里引出了分布式系统的cap理论：

一致性 （consistency）：分布式系统中的所有数据，同一时刻有着相同的值。

        业务代码将数据A写入库01，01把A同步给02数据库，业务代码从02中读取出记录也是A，那么这两个数据库存放的数据就是一致的。

可用性（Avalibability）：分布式系统中一部份节点出现故障，分布式系统仍旧可以响应用户的请求。

        数据库01和02同时存放记录A，数据库01挂掉，业务代码可以继续从02获取记录A,也就是在节点出现问题的时候，还保证数据的可用性。

分区容错性（Partition tolerance）：两个数据库节点分别在两个区，而两个区的通讯发生了问题，就不能达成数据一致，这就是分区的情况，我们就需要从C和A中做出选择。

        是选择可用性A，获取其中一个区的数据，还是选择一致性C，等待两个区的数据同步了再去获取数据。

CAP只能同时满足其中两个CP或者AP；