分库分表
1.垂直拆分 / 水平拆分？表太多 还是 数据太多？
如果是表太多,则应该将部分表进行迁移(可以按业务区分),这就是所谓的垂直切分。
如果是数据量太大,则需要将表拆成更多的小表,来减少单表的数据量,这就是所谓的水平拆分。
垂直拆分
垂直分库
垂直分库针对的是一个系统中的不同业务进行拆分,比如用户一个库,商品一个库,订单一个库。 一个购物网站对外提供服务时,会同时对用户、商品、订单表进行操作。
垂直分表
表中的字段较多，将不常用的， 数据较大，长度较长（比如text类型字段）的拆分到“扩展表“。
水平拆分
水平分表
垂直分表是基于列的,而水平分表是基于全表的。
水平分库分表
水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。
分库分表策略
HASH取模
假设有用户表user,将其分成3个表user0,user1,user2.路由规则是对3取模,当uid=1时,对应到的是user1,uid=2时,对应的是user2.
范围分片
从1-10000一个表,10001-20000一个表。
地理位置分片
华南区一个表,华北一个表。
时间分片
按月分片，按季度分片等等,可以做到冷热数据。
分库分表注意点
分布式事务问题
如果我们做了垂直分库或者水平分库以后,就必然会涉及到跨库执行SQL的问题,这样就引发了互联网界的老大难问题-"分布式事务"。那要如何解决这个问题呢？
1.使用分布式事务中间件 2.使用MySQL自带的针对跨库的事务一致性方案(XA),不过性能要比单库的慢10倍左右。3.能否避免掉跨库操作(比如将用户和商品放在同一个库中)
跨库join的问题
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。粗略的解决方法： 全局表：基础数据，所有库都拷贝一份。 字段冗余：这样有些字段就不用join去查询了。 系统层组装：分别查询出所有，然后组装起来，较复杂。
跨节点Join的问题：解决这一问题的普遍做法是分两次查询实现
横向扩容的问题
当我们使用HASH取模做分表的时候,针对数据量的递增,可能需要动态的增加表,此时就需要考虑因为reHash导致数据迁移的问题。
结果集合并、排序的问题
因为我们是将数据分散存储到不同的库、表里的,当我们查询指定数据列表时,数据来源于不同的子库或者子表,就必然会引发结果集合并、排序的问题。如果每次查询都需要排序、合并等操作,性能肯定会受非常大的影响。走缓存可能一条路!
Mycat
拆分工具：Mycat 分布式数据库的中间件
关键词：“拦截”，
它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，
然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
|
中间件
|
例如淘宝开源的cobar，以及后来开源社区根据cobar做二次开发的Mycat（个人建议如果使用中间件的话可以考虑Mycat）
|
|
Jar形式的开源工具
|
例如淘宝的TDDL，以及当当开源出来的，Sharding-JDBC等
|
|
动态数据源
|
根据自己的业务来指定数据源来完成不同库和表的操作
|
逻辑库
逻辑表
分片表
全局表
ER表（一对多关系）
非分片表
server.xml
schema.xml
rule.xml
Mycat和MySQL的区别（Mycat的核心作用）：
当我们的应用只需要一台数据库服务器的时候我们并不需要Mycat，而如果你需要分库甚至分表，这时候应用要面对很多个数据库的时候，这个时候就需要对数据库层做一个抽象，来管理这些数据库，而最上面的应用只需要面对一个数据库层的抽象或者说数据库中间件就好了，这就是Mycat的核心作用。所以可以这样理解：数据库是对底层存储文件的抽象，而Mycat是对数据库的抽象。
分库分表方案
1.热数据和冷数据
热数据：3个月内的订单数据，查询实时性较高。
冷数据A：3个月 ~ 12个月前的订单数据，查询频率不高。
冷数据B：1年前的订单数据，几乎不会查询，只有偶尔的查询需求。
对于这三类数据的存储，目前规划如下：
热数据： 使用mysql进行存储，当然需要分库分表
冷数据A: 对于这类数据可以存储在ES中，利用搜索引擎的特性基本上也可以做到比较快的查询。
冷数据B: 对于这类不经常查询的数据，可以存放到hive中
如何分库分表
一、按业务拆分
我们将不同的业务放到不同的库中，将原来所有压力由同一个库中分散到不同的库中，提升了系统的吞吐量。