分库分表笔记整理

sharding指随着业务的增长将原来的一个大数据库根据某种策略拆分成多个数据库或表，存储到不同的物理节点。包含不限于常见的垂直切分和水平切分。既然一个数据库被划分到了不同节点，那么就需要一个服务来对原来的查询路由转发到不同分片上。

一、mysql的分表sharding策略：

mysql的分表是真正的分表，一张表分成很多表后，每一个小表都是完正的一张表，都对应三个文件（MyISAM引擎：一个.MYD数据文件，.MYI索引文件，.frm表结构文件）。

• 水平(横向)拆分：将同一个表的数据进行分块保存到不同的数据库中，来解决单表中数据量增长出现的压力。这些数据库中的表结构完全相同。
• 垂直(纵向)拆分：是指按功能模块拆分，以解决表与表之间的IO竞争。比如分为订单库、商品库、用户库，这种方式多个数据库之间的表结构不同。

场景需求：

• 垂直切分。

1.大字段的切分。将大字段存储到扩展表，提高基础表的访问性能。

2.按照使用用途垂直切分。例如企业物料属性，可以按照基本属性、销售属性、采购属性、生产制造属性、财务会计属性等用途垂直切分。

3.按照访问频率垂直切分。例如电子商务、Web 2.0系统中，如果用户属性设置非常多，可以将基本、使用频繁的属性和不常用的属性垂直切分开。

• 水平切分

1.根据时间切分。比如在线电子商务网站，订单表数据量过大，按照年度、月度水平切分。

2.根据用户地域范围切分。如华北，华南。

3.置顶帖。由于每页都需要显示置顶帖，所以可以将置顶的记录单独存储一张表。

二、mysql分库

分表能够解决单表数据量过大带来的查询效率下降的问题，但是，却无法给数据库的并发处理能力带来质的提升。面对高并发的读写访问，当数据库master服务器无法承载写操作压力时，不管如何扩展slave服务器，此时都没有意义了。因此，我们必须换一种思路，对数据库进行拆分，从而提高数据库写入能力，这就是所谓的分库。

与分表策略相似，分库可以采用通过一个关键字取模的方式，来对数据访问进行路由，如下图所示:

三、分库分表后存在的问题

问题：

• 事务问题。由于数据分布到了不同节点，数据库事务管理出现了问题。一方面数据库自身的分布式事务管理会付出高昂的性能代价，另一方面从代码逻辑上会更加复杂。
• 跨库跨表的join问题。在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
• 额外的数据管理和运算能力。额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order by语句就可以搞定，但是在进行分表之后，将需要n个order by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。（类似于先map，再reduce，分而治之再归并）

解决方案：

使用类似JTA提供的分布式事务机制。

使用流水处理器异步解决。

主流的分布式事务解决方案有三种：两阶段提交协议、最大努力保证模式和事务补偿机制。

四、分库分表的中间件