mysql分表分库

1.分表

当一张表的数据达到几千万时（超过500万条记录就可以考虑），你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。

mysql中有一种机制是表锁定和行锁定，是为了保证数据的完整性。表锁定表示你们都不能对这张表进行操作，必须等我对表操作完才行。行锁定也一样，别的sql必须等我对这条数据操作完了，才能对这条数据进行操作。

建议：对应分表可以采用取模进行判断，比如模10.

另外也可以用merge存储引擎实现分表：

 

2.主从

MySQL的主从复制解决了数据库的读写分离，并很好的提升了读的性能，其图如下：

 

其主从复制的过程如下图所示：

 

但是，主从复制也带来其他一系列性能瓶颈问题：

1. 写入无法扩展

2. 写入无法缓存

3. 复制延时

4. 锁表率上升

5. 表变大，缓存率下降

那问题产生总得解决的，这就产生下面的优化方案，一起来看看。

 

1.Mysqlcluster数据节点组内主从同步采用的是同步复制，来保证组内节点数据的一致性。一般通过两阶段提交 协议来实现，一般工作过程如下：

a)Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。

b)每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。

c)Master等待所有Slave发送OK或ABORT消息

      如果Master收到所有 Slave的OK消息，它就会向所有Slave发送提交消息，告诉Slave提交该事务；

      如果Master收到来自任何一个Slave的ABORT消息，它就向所有 Slave发送ABORT消息，告诉Slave去中止事务。

e)每个Slave等待来自Master的OK或ABORT消息。

         如果Slave收到提交请求，它们就会提交事务，并向Master发送事务已提交 的确认；

         如果Slave收到取消请求,它们就会撤销所有改变并释放所占有的资源，从而中止事务，然后向Masterv送事务已中止的确认。

f)      当Master收到来自所有Slave的确认后，就会报告该事务被提交（或中止），然后继续进行下一个事务处理。

由于同步复制一共需要4次消息传递，故mysql  cluster的数据更新速度比单机mysql要慢。所以mysql cluster要求运行在千兆以上的局域网内，节点可以采用双网卡，节点组之间采用直连方式。

 

适合微博模式。

 

3.分库

这是一个非常好的思路，将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可，原理图如下：

 

如何来确定某个用户所在的shard呢，可以建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，如下图所示：

 

 

 

 

参考：https://my.oschina.net/ydsakyclguozi/blog/199498