今天学习了数据库分表分库，感觉记录下一些东西以便以后的查看。

1、数据库建立索引，可以加快表数据的查询，但是过多的索引，会占用大量的内存，维护难度较大，因为索引底层的算法是B-tree,树的特点就是查找数据快按时数据增删改比较慢。

2、数据库的表拆分，分为水平拆分，垂直拆分，水平垂直拆分（自定义的）。

3、mycat：数据库的中间件，数据库的代理，屏蔽物理数据库的，支持多种拆分结构。

一、水平拆分：（部分摘自：https://www.cnblogs.com/firstdream/p/6728106.html）

1）、把同一个表拆到不同的数据库中。

2）、垂直拆分后遇到单机瓶颈，可以使用水平拆分。

3）、水平拆分不是将表的数据做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中，主要有分表，分库两种模式，如图：

优点：

1. 不存在单库大数据，高并发的性能瓶颈。

2. 对应用透明，应用端改造较少。

3. 按照合理拆分规则拆分，join操作基本避免跨库。

4. 提高了系统的稳定性跟负载能力。

5. 切分策略简单，根据uid，按照范围，user- center很快能够定位到数据在哪个库上，扩容简单，如果容量不够，只要增加数据库即可（用户表实际场景）

缺点：

1. 拆分规则难以抽象。

2. 分片事务一致性难以解决。

3. 数据多次扩展难度跟维护量极大。

4. 跨库join性能较差。

5.数据量不均，新增的user-db3，在初期的数据会比较少，请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡。（用户表的实际场景）

二、垂直拆分：

1）、垂直拆分是把不同的表拆到不同的数据库中。

2）、按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面。

优点：

1. 拆分后业务清晰，拆分规则明确。

2. 系统之间整合或扩展容易。

3. 数据维护简单。

缺点：

1. 部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。

2. 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。

3. 事务处理复杂。

三、数据库切分方法|哈希法

优点：

•切分策略简单，根据uid，按照范围，快速定位到分布的数据库中。

•数据量均衡：只要uid是均衡的，数据分布在各个库是均衡的。

•请求量均衡：只要uid是均衡的，每个库负载也相对是均衡的。

缺点：

1、扩容麻烦，如果需要增加一个库，需要重新hash，这有可能会导致数据迁移，给平滑升级带来困难。

四、真实的业务场景：

1）、订单中心数据库切分方法|数据冗余法（部分参考原文：https://blog.csdn.net/sunhuiliang85/article/details/78418546 ）

互联网数据量很大的业务场景，往往数据库需要进行水平切分来降低单库数据量。

水平切分会有一个patitionkey，通过patition key的查询能够直接定位到库，但是非patitionkey上的查询可能就需要扫描多个库了。

此时常见的架构设计方案，是使用数据冗余这种反范式设计来满足分库后不同维度的查询需求。

订单表可以中可以存订单编号，卖家的编号，买家的编号，同时再以买家编号为主键建立买家表，再以卖家编号为主键建立卖家表。