分库

例如将商城系统单体架构按照功能模块拆分为子服务，比如：Portal 服务、用户服务、订单服务、库存服务等。

分表

垂直拆分：拿用户表（user）来说，表中有 7 个字段：id,name,age,sex,nickname,description，如果 nickname 和 description 不常用，我们可以将其拆分为另外一张表：用户详细信息表，这样就由一张用户表拆分为了用户基本信息表+用户详细信息表
水平拆分：
比如表中有一万条数据，我们拆分为两张表，id 为奇数的：1，3，5，7……放在 user1 中， id 为偶数的：2，4，6，8……放在 user2 中，这样的拆分办法就是水平拆分了。
比如订单表，可以按每日、每月等进行拆分。
每日表：只存储当天的数据。
每月表：可以起一个定时任务将前一天的数据全部迁移到当月表。
历史表：同样可以用定时任务把时间超过 30 天的数据迁移到 history 表。

带来问题

跨库关联查询

在单库未拆分表之前，我们可以很方便使用 join 操作关联多张表查询数据，但是经过分库分表后两张表可能都不在一个数据库中，如何使用 join 呢？
有几种方案可以解决：
字段冗余：把需要关联的字段放入主表中，避免 join 操作；
数据抽象：通过 ETL 等将数据汇合聚集，生成新的表；A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步。当然，同步本来会对数据库带来一定的影响，需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询。
全局表：比如一些基础表可以在每个数据库中都放一份；
应用层组装：将基础数据查出来，通过应用程序计算组装；

分布式事务

单数据库可以用本地事务搞定，使用多数据库就只能通过分布式事务解决了。
常用解决方案有：基于可靠消息（MQ）的解决方案、两阶段事务提交、柔性事务等。

排序、分页、函数计算问题

在使用 SQL 时 order by、limit 等关键字需要特殊处理，一般来说采用分片的思路：
先在每个分片上执行相应的函数，然后将各个分片的结果集进行汇总和再次计算，最终得到结果。
比如有两个节点，节点1 存的是奇数id=1,3,5,7,9……；节点2 存的是偶数id=2,4,6,8,10……执行select * from user_info order by id limit 0,10
需要在两个节点上各取出10 条，然后合并数据，重新排序。

分布式 ID

如果使用 Mysql 数据库在单库单表可以使用 id 自增作为主键，分库分表了之后就不行了，会出现 id 重复。
常用的分布式 ID 解决方案有：

• 雪花算法（Snowflake），推荐使用
• 基于数据库自增单独维护一张 ID表
• UUID，由于 UUID 生成的主键是字符串占用空间很大，并且具有很大的随机性，生成的主键不能全局递增，非递增的主键会导致 mysql 大量的页裂和记录移动，所以性能非常差，所以该方案基本无法使用。
• Redis 缓存，incr自增
• 号段模式
• 百度 uid-generator
• 美团 Leaf
• 滴滴 Tinyid

  多数据源

  分库分表之后可能会面临从多个数据库或多个子表中获取数据，一般的解决思路有：客户端适配和代理层适配。
  业界常用的中间件有：
  shardingsphere（前身 sharding-jdbc）
  Mycat