DB的分库分表

分表（只能解决数据量过大带来查询效率下降的问题，无法解决并发问题）

对于访问极为频繁且数据量巨大的单表来说，我们首先要做的，就是减少单表的记录条数，以便减少数据查询所需要的时间，提高数据库的吞吐，这就是所谓的分表。（减少数据库的吞吐，就是减少数据库容量。）

首先需要选择适当的分表策略，使得数据能够较为均衡的分布到多张表中，并且，不影响正常的查询。

案例：

对于互联网企业来说，大部分数据都是与用户进行关联的，因此，用户id是最常用的分表字段，因为大部分查询都需要带上用户id，这样既不影响查询，又能够使数据较为均衡的分布到各个表中。

(当数据量达到一定数量时定时跑批拆分记录，通过单个表分成256个表)

订单表：拆分记录根据ueerid%256，取得每个订单存的是哪个表，前端根据userid%256来找对应的表来进行访问，这样的话userid就成了一个必须的查询条件，因为如果没有带用户id，就不知道在那张表去查他的数据。如果userid为257，那就%256，那么就知道去第一张表去查数据。

 

 

分库（给数据库处理并发问题来质的提升）

面对高并发的读写访问，当数据库master服务器无法承载写操作压力时，不管如何扩展slave服务器，此时都没有意义了。因此，我们必须换一种思路，对数据库进行拆分，从而提高数据库写入能力，这就是所谓的分库。

 

通过单个库分成256个库。

 

 

分库分表

数据库可能即面临着高并发访问的压力，又需要面对海量数据的存储问题，这时候，需要对数据库即采用分库策略，又采用分表策略，以便同时扩展系统的并发处理能力，以及提升单表的查询性

能，这就是所谓的 分库分表。

公式：被分库和被分表的数量更换。

中间变量=user_id%(库数量*每个库的表数量)

库=取整(中间变量/每个库的表数量)

表=中间变量%每个库的表数量

 

 

分库分表策略（先分库在分表）

 

假设将原来的单库单表order拆分成256个库，每个库包含1024个表，

那么，按照前面所提到的路由策略，对于userid=262145的访问，

路由的计算过程如下：

中间变量=262145%(256*1024)=1

库=取整(1/1024)=0

表=1%1024=1

这意味着，对于userid=262145的订单记录的查询和修改，将被路

由到第0个库的第1个表中执行。

拉主从而不进行读写分离的公司：主要是想利用从库做数据库的备份。

分库分表带来的限制

1.条件查询、分页查询受到限制，查询必须带上分库分表所带上的id。

2.事务可能跨多个库，数据一致性无法通过本地事务实现，无法使用外键（要使用分布式事务）。

3.分库分表规则确定以后，扩展变更规则需要迁移数据

4.如果是海量重要的数据，就要是分库分表，如果数据只是针对当前这段时间比较重要，但数据增长的又快，如有上千万，那可以每隔一段时间将这些数据清理掉，如客户的预约数据。