MySQL分库分表方案

1.为何要分表：

当一张表的数据达到几千万时，你查询一次所花的时间会变多，若是有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减少数据库的负担，缩短查询时间。

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

2. mysql proxy：amoeba

作mysql集群,利用amoeba。

从上层的java程序来说，不须要知道主服务器和从服务器的来源，即主从数据库服务器对于上层来说是透明的。能够经过amoeba来配置。

3.大数据量而且访问频繁的表，将其分为若干个表

好比对于某网站平台的数据库表-公司表，数据量很大，这种能预估出来的大数据量表，咱们就事先分出个N个表，这个N是多少，根据实际状况而定。

某网站如今的数据量至可能是5000万条，能够设计每张表容纳的数据量是500万条，也就是拆分红10张表，

那么如何判断某张表的数据是否容量已满呢？能够在程序段对于要新增数据的表，在插入前先作统计表记录数量的操做，当<500万条数据，就直接插入，当已经到达阀值，能够在程序段新建立数据库表（或者已经事先建立好），再执行插入操做。

4. 利用merge存储引擎来实现分表

若是要把已有的大数据量表分开比较痛苦，最痛苦的事就是改代码，由于程序里面的sql语句已经写好了。用merge存储引擎来实现分表, 这种方法比较适合.

举例子：

------------------- ----------华丽的分割线--------------------------------------

数据库架构

一、简单的MySQL主从复制:

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

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

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

1. 写入没法扩展

2. 写入没法缓存

3. 复制延时

4. 锁表率上升

5. 表变大，缓存率降低

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

二、MySQL垂直分区

若是把业务切割得足够独立，那把不一样业务的数据放到不一样的数据库服务器将是一个不错的方案，并且万一其中一个业务崩溃了也不会影响其余业务的正常进行，而且也起到了负载分流的做用，大大提高了数据库的吞吐能力。通过垂直分区后的数据库架构图以下：

然而，尽管业务之间已经足够独立了，可是有些业务之间或多或少总会有点联系，如用户，基本上都会和每一个业务相关联，何况这种分区方式，也不能解决单张表数据量暴涨的问题，所以为什么不试试水平分割呢？

三、MySQL水平分片（Sharding）

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

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