ShardingSphere 系列（2）—分库分表如何落地

从数据存储和访问的演进过程说起

以 MySQL 为代表的关系型数据库中的单表无法支持大数据量的存储和访问方案，自然而然的，你可能会想到是否可以采用诸如 MongoDB 等 NoSQL 的方式来管理数据？

但这并不是一个很好的选项，原因有很多：

• 关系型生态系统非常完善
• 关系型数据库的事务特性

分库分表方案更多的是对关系型数据库数据存储和访问机制的一种补充，而不是颠覆

一、什么是数据分库分表？

为了解决由于数据量过大而导致的数据库性能降低的问题，将原来独立的数据库拆分成若干数据库，把原来数据量大的表拆分成若干数据表，使得单一数据库、单一数据表的数据量变得足够小，从而达到提升数据库性能的效果

二、分库分表的表现形式

分库分表包括分库和分表两个维度，在开发过程中，对于每个维度都可以采用两种拆分思路，即 垂直拆分 和 水平拆分：

先来讨论垂直拆分的应用方式，相比水平拆分，垂直拆分相对比较容易理解和实现。在电商系统中，用户在打开首页时，往往会加载一些用户性别、地理位置等基础数据。对于用户表而言，这些位于首页的基础数据访问频率显然要比用户头像等数据更高。基于这两种数据的不同访问特性，可以把用户单表进行拆分，将访问频次低的用户头像等信息单独存放在一张表中，把访问频次较高的用户信息单独放在另一张表中：

从这里可以看到，垂直分表的处理方式就是将一个表按照字段分成多张表，每个表存储其中一部分字段。 在实现上，我们通常会把头像等 b