分库分表
简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。
说到分库分表之前，需要先说说分区的概念
分区：在单机中，将一张表的数据分成N个放置在磁盘内，分区的作用是将一张表分配为多个区块存储到一起。（缺点：数据库内部实现，研发执行不可控。可与分库分表结合使用）
分库:
数据库集群环境，一个库里表太多了，导致了海量数据，系统性能下降，把原本存储于一个库的表拆分存储到多个库上，通常是将表按照功能模块、关系密切程度划分出来，部署到不同库上。
少增量数据写入时的锁对查询的影响
由于单表数量下降，常见的查询操作由于减少了需要扫描的记录，使得单表单次查询所需的检索行数变少，减少了磁盘IO，时延变短
分表：
水平拆分：
单表的容量不超过500W，否则建议水平拆分。把一个表复制成同样表结构的不同表，然后把数据按照一定的规则划分，分别存储到这些表中，从而保证单表的容量不会太大，提升性能；当然这些结构一样的表，可以放在一个或多个数据库中。
主要方法：MD5 hash方法、按照时间、按照用户ID拆分
垂直拆分：
按照业务线进行拆分，业务功能的使用频次。把主要的、热门的字段放在一起做为主要表。然后把不常用的，拆分到不同的次要表中；主要表和次要表的关系一般都是一对一的。
分库分表存在的问题。
- 事务问题
- 跨库跨表的join问题
- 额外的数据管理负担和数据运算压力。
数据的定位问题和数据的增删改查的重复执行问题，通过应用程序解决，会引起额外的逻辑运算。
分库分表
主从复制
slave 会从 master 读取 binlog 来进行数据同步
- master将改变记录到二进制日志（binary log）。这些记录过程叫做二进制日志事件；
- salve 将 master 的 binary log events 拷贝到它的中继日志（relay log）;
- slave 重做中继日志中的事件，将改变应用到自己的数据库中。
MySQL 复制是异步且是串行化的。
复制的基本原则（一主多从、主主复制）
- 每个 slave只有一个 master
- 每个 salve只能有一个唯一的服务器 ID
- 每个master可以有多个salve
复制的最大问题：延时、主从复制过程中的性能问题。
MySQL一主多从
hummingbird
