<!-- Baidu Button BEGIN -->
Summary of MySQL sub-database and sub-table:
Single library single table:
Single database single table is the most common database design. For example, there is a user (user) table in the database db, and all users can be found in the user table in the db database.
Single library with multiple tables:
As the number of users increases, the amount of data in the user table will increase. When the amount of data reaches a certain level, the query on the user table will gradually slow down, thus affecting the performance of the entire DB. If using
MySQL, and a more serious problem is that when a column needs to be added, MySQL will lock the table, and all read and write operations can only wait. Users can be divided horizontally in some way to generate two tables with exactly the same structure as user_0000, user_0001, etc. The data of user_0000 + user_0001 + ... is just a complete data.
Multi-cudo table:
As the amount of data increases, the storage space of a single DB may not be enough, and as the amount of queries increases, a single database server can no longer support it. At this time, the database can be divided horizontally.
Sub-library and sub-table rules:
When designing a table, it is necessary to determine what rules the table is divided into. For example, when there is a new user, the program has to determine which table to add the user information to; similarly, when logging in, we have to find the corresponding record in the database through the user's account, all of which need to follow a certain rule conduct.
Routing
is the process of finding the corresponding table and library through the sub-library and sub-table rules. For example, the rule of sub-database sub-table is user_id mod 4. When a user registers a new account, the account id is 123, we can pass
It is determined by id mod 4 that this account should be saved in the User_0003 table. When user 123 logs in, we confirm that it is recorded in User_0003 after passing 123 mod 4.
Problems arising from sub-database and sub-table, and matters needing attention
1. The problem of sub-database and sub-table dimensions
假如用户购买了商品,需要将交易记录保存取来，如果按照用户的纬度分表，则每个用户的交易记录都保存在同一表中，所以很快很方便的查找到某用
户的购买情况，但是某商品被购买的情况则很有可能分布在多张表中，查找起来比较麻烦。反之，按照商品维度分表，可以很方便的查找到此商品的购
买情况，但要查找到买人的交易记录比较麻烦。
所以常见的解决方式有：
a.通过扫表的方式解决，此方法基本不可能，效率太低了。
b.记录两份数据，一份按照用户纬度分表，一份按照商品维度分表。
c.通过搜索引擎解决，但如果实时性要求很高，又得关系到实时搜索。
2. 联合查询的问题
联合查询基本不可能，因为关联的表有可能不在同一数据库中。
3. 避免跨库事务
避免在一个事务中修改db0中的表的时候同时修改db1中的表，一个是操作起来更复杂，效率也会有一定影响。
4. 尽量把同一组数据放到同一DB服务器上
例如将卖家a的商品和交易信息都放到db0中，当db1挂了的时候，卖家a相关的东西可以正常使用。也就是说避免数据库中的数据依赖另一数据库中的数据。
一主多备
在实际的应用中，绝大部分情况都是读远大于写。Mysql提供了读写分离的机制，所有的写操作都必须对应到Master，读操作可以在Master和Slave机器上进行，Slave与Master的结构完全一样，一个Master可以有多个Slave,甚至Slave下还可以挂Slave,通过此方式可以有效的提高DB集群的QPS.
所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。
此外，可以看出Master是集群的瓶颈，当写操作过多，会严重影响到Master的稳定性，如果Master挂掉，整个集群都将不能正常工作。
所以，1. 当读压力很大的时候，可以考虑添加Slave机器的分式解决，但是当Slave机器达到一定的数量就得考虑分库了。 2. 当写压力很大的时候，就必须得进行分库操作。
---------------------------------------------
MySQL使用为什么要分库分表
可以用说用到MySQL的地方,只要数据量一大, 马上就会遇到一个问题,要分库分表.
这里引用一个问题为什么要分库分表呢?MySQL处理不了大的表吗?
其实是可以处理的大表的.我所经历的项目中单表物理上文件大小在80G多,单表记录数在5亿以上,而且这个表
属于一个非常核用的表:朋友关系表.
但这种方式可以说不是一个最佳方式. 因为面临文件系统如Ext3文件系统对大于大文件处理上也有许多问题.
这个层面可以用xfs文件系统进行替换.但MySQL单表太大后有一个问题是不好解决: 表结构调整相关的操作基
本不在可能.所以大项在使用中都会面监着分库分表的应用.
从Innodb本身来讲数据文件的Btree上只有两个锁, 叶子节点锁和子节点锁,可以想而知道,当发生页拆分或是添加
新叶时都会造成表里不能写入数据.
所以分库分表还就是一个比较好的选择了.
那么分库分表多少合适呢?
经测试在单表1000万条记录一下,写入读取性能是比较好的. 这样在留点buffer,那么单表全是数据字型的保持在
800万条记录以下, 有字符型的单表保持在500万以下.
如果按 100库100表来规划,如用户业务:
500万*100*100 = 50000000万 = 5000亿记录.
心里有一个数了,按业务做规划还是比较容易的.
分布式数据库架构--排序、分页、分组、实现
最近研究分布式数据库架构，发现排序、分组及分页让着实人有点头疼。现把问题及解决思路整理如下。
一、 多分片（水平切分）返回结果合并（排序）
1、Select + None Aggregate Function的有序记录合并排序
解决思路：对各分片返回的有序记录，进行排序去重合并。此处主要是编写排序去重合
并算法。
2、Select + None Aggregate Function的无序记录合并
解决思路：对各分片返回的无序记录，进行去重合并。
优点：实现比较简单。
缺点：数据量越大，字段越多，去重处理就会越耗时。
3、Select + Aggregate Function的记录合并（排序）
Oracle常用聚合函数：Count、Max、Min、Avg、Sum。
AF：Max、Min
思路：通过算法对各分片返回结果再求max、min值。
AF：Avg、Sum、Count
思路：分片间无重复记录或字段时，通过算法对各分片返回结果再求avg、sum、count值。分片间有重复记录或字段时，先对各分片记录去重合并，再通过算法求avg、sum、count值。
比如：
select count(*) from user
select count(deptno) from user;
select count(distinct deptno) from user;
二、多分片（水平切分）返回结果分页
解决思路：合并各分片返回结果，逻辑分页。
优点： 实现简单。
缺点： 数据量越大，缓存压力就越大。
分片数据量越大，查询也会越慢。
三、多分片（水平切分）查询有分组语法的合并
1、Group By Having + None Aggregate Function时
Select + None Aggregate Function
比如：select job user group by job;
思路：直接去重（排序）合并。
Select + Aggregate Function
比如：select max(sal),job user group by job;
思路：同Select + Aggregate Function的记录合并（排序）。
2、Group By Having + Aggregate Function时
解决思路：去掉having AF条件查询各分片，然后把数据放到一张表里。再用group by having 聚合函数查询。
四、分布式数据库架构--排序分组分页参考解决方案
解决方案1：Hadoop + Hive。
思路：使用Hadoop HDFS来存储数据，通过Hdoop MapReduce完成数据计算，通过Hive HQL语言使用部分与RDBBS一样的表格查询特性和分布式存储计算特性。
优点： 可以解决问题
具有并发处理能力
可以离线处理
缺点： 实时性不能保证
网络延迟会增加
异常捕获难度增加
Web应用起来比较复杂
解决方案2：总库集中查询。
优点： 可以解决问题
实现简单
缺点： 总库数据不能太大
并发压力大
五、小结
对 于分布式数据库架构来说，排序、分页、分组一直就是一个比较复杂的问题。避免此问题需要好好地设计分库、分表策略。同时根据特定的场景来解决问题。也可以 充分利用海量数据存储（Hadoop-HDFS|Hive|HBse）、搜索引擎（Lucene|Solr）及分布式计算（MapReduce）等技术来 解决问题。
别外，也可以用NoSQL技术替代关系性数据库来解决问题，比如MogonDB\redis。
最近研究分布式数据库架构，发现排序、分组及分页让着实人有点头疼。现把问题及解决思路整理如下。
一、 多分片（水平切分）返回结果合并（排序）
1、Select + None Aggregate Function的有序记录合并排序
解决思路：对各分片返回的有序记录，进行排序去重合并。此处主要是编写排序去重合
并算法。
2、Select + None Aggregate Function的无序记录合并
解决思路：对各分片返回的无序记录，进行去重合并。
优点：实现比较简单。
缺点：数据量越大，字段越多，去重处理就会越耗时。
3、Select + Aggregate Function的记录合并（排序）
Oracle常用聚合函数：Count、Max、Min、Avg、Sum。
AF：Max、Min
思路：通过算法对各分片返回结果再求max、min值。
AF：Avg、Sum、Count
思路：分片间无重复记录或字段时，通过算法对各分片返回结果再求avg、sum、count值。分片间有重复记录或字段时，先对各分片记录去重合并，再通过算法求avg、sum、count值。
比如：
select count(*) from user
select count(deptno) from user;
select count(distinct deptno) from user;
二、多分片（水平切分）返回结果分页
解决思路：合并各分片返回结果，逻辑分页。
优点： 实现简单。
缺点： 数据量越大，缓存压力就越大。
分片数据量越大，查询也会越慢。
三、多分片（水平切分）查询有分组语法的合并
1、Group By Having + None Aggregate Function时
Select + None Aggregate Function
比如：select job user group by job;
思路：直接去重（排序）合并。
Select + Aggregate Function
比如：select max(sal),job user group by job;
思路：同Select + Aggregate Function的记录合并（排序）。
2、Group By Having + Aggregate Function时
解决思路：去掉having AF条件查询各分片，然后把数据放到一张表里。再用group by having 聚合函数查询。
四、分布式数据库架构--排序分组分页参考解决方案
解决方案1：Hadoop + Hive。
思路：使用Hadoop HDFS来存储数据，通过Hdoop MapReduce完成数据计算，通过Hive HQL语言使用部分与RDBBS一样的表格查询特性和分布式存储计算特性。
优点： 可以解决问题
具有并发处理能力
可以离线处理
缺点： 实时性不能保证
网络延迟会增加
异常捕获难度增加
Web应用起来比较复杂
解决方案2：总库集中查询。
优点： 可以解决问题
实现简单
缺点： 总库数据不能太大
并发压力大
五、小结
对 于分布式数据库架构来说，排序、分页、分组一直就是一个比较复杂的问题。避免此问题需要好好地设计分库、分表策略。同时根据特定的场景来解决问题。也可以 充分利用海量数据存储（Hadoop-HDFS|Hive|HBse）、搜索引擎（Lucene|Solr）及分布式计算（MapReduce）等技术来 解决问题。
别外，也可以用NoSQL技术替代关系性数据库来解决问题，比如MogonDB\redis。