1. 为什么需要分库分表？

关系型数据库，表中管理的数据以行记录为单元。当一张表的数据达到上千万条时，随之带来的是更高的磁盘、IO、系统开销，更复杂的索引维护，以及性能上的瓶颈。而一台服务的资源终究是有限的，因此需要对数据库和表进行合理拆分，从而使其更好的提供数据服务。

分库分表的目的在于：减小数据库的负担，提高数据库的效率，缩短查询时间。另外，因为分库分表这种改造是可控的，底层还是基于数据库管理系统，因此整个数据库的运维体系以及相关基础设施都是可重用的。

分库概念：一个系统的多张数据表，存储到多个数据库实例中；

分表概念：对于一张多行(记录)多列(字段)的二维数据表，分两种分表操作：

• （1） 垂直分表: 竖向切分，不同分表存储不同的字段，可以把不常用或者大容量、或者不同业务的字段拆分出去； 优点：可以实现热数据和冷数据的分离，将不经常变化的数据和变动较大的数据分散再不同的库/表中。 缺点：没有解决数据量大带来的性能损耗，读写压力依旧很大。
• （2） 水平分表(复杂): 横向切分，按照特定分片算法，不同分表存储不同的记录。例如根据年份来拆分不同的数据库。每个数据库结构一致，但是数据得以拆分，每个子表记录数量得到降低，从而提升性能。 优点：单库（表）的数据量得以减少，提高性能。提高了系统的稳定性和负载能力。切分出的表结构相同，应用程序只需要做子表的映射即可。 缺点：数据分片在扩容时需要迁移。数据库维护成本增加。

2. 主从复制，读写分离

高并发业务服务器端，如果将对数据库的读和写都放在同一个数据库实例中，无疑是低效率的。因为读、写操作会涉及到锁的竞争，尤其是写操作，通常一个事务进行写操作时，其它并发的事务则会因为排他锁而阻塞。而在实际的业务作业中，对数据库的操作总是读多写少的，并且读的效率也高于写操作。因此，将数据库架构设计成主从集群，读写业务分离，对于高并发的数据访问是高效的解决方法。

主从架构除了带来支持高并发的优点，还使得MySQL数据库具有高可用的能力。主从架构中，若主服务器宕机，从服务器可以快速顶替，使得服务器具有高可用、容灾能力。

2.1 主从架构

如图所示为3个节点的主从架构的基本示意图，3个MySQL集群中1个节点为主库(Master)，2个节点为从节点(Slave):

• 1.主库负责接收用户的写操作，并通过更新二进制日志BINLOG通知从库更新数据。
• 2.从库主要负责用户的读操作(分担主服务器的读写压力)，并且负责重放Master的写操作(即复制主库做的写操作)，从而保证集群数据一致性、高可用、实现容灾能力。
• 3.Proxy: sql语句代理，对读写操作请求的SQL指令进行路由，使得读写分离。
• 4.Direct: 负载均衡组件, 对Mysql Proxy分发得读操作，按照一定得一致性哈希等算法进行分发至后端的从库。

2.2 MySQL数据复制过程解析(Replication)

MySQL的数据复制(Replication)过程是将一个MySQL实例中的数据复制到另一个MySQL实例中。

MySQL的复制（replication）是一个异步的复制，从一个MySQLinstace（Master）复制到另一个MySQLinstance（Slave）。Replication功能的出现能够非常方便将某一数据库中的数据复制到多台服务器中的数据里实例中，从而实现数据备份、主从热备、数据库集群等功能。且整个过程是异步进行的，复制的延时非常小，有效的提高了数据库的处理能力，提高了数据安全性等。

整个复制操作主要由三个进程完成的，其中两个进程在Slave服务器上（Sql进程和IO进程），另外一个进程在Master服务器（IO进程）上。

要实施复制，首先必须打开Master端的bin-log功能，整个复制过程实际上就是Slave