[toc]

谈一谈分表设计

在一个可预见的，能运行比较长，数据量可能比较大的业务场景中，经常需要分库分表，因为单表存储能力和查询能力都是有上限的。一般如果业务还是要正常跑下去的话，都要进行迁移，比如迁移到能水平扩展的存储（如tidb, mongodb等）。但是在初期，业务还没有起量的时候或者说不能预见能起量的时候，都是采用传统的分库分表方法来解决。这篇文章只谈分表。

需要分表的场景

一般来说，数据是膨胀类增长时，比如线性增长，指数增长，这些场景都需要分表。举个例子，用户订单表，购买记录流水表，收支流水记录，发放记录流水，操作记录表。一个用户的操作可能产生几倍的数据增长。

分表设计的原则

• 满足业务的需求
• 能保持数据不恶化

说下不恶化这个原则，也就是在业务随着时间向前推进增长的情况下，系统能正常运行。

常用分表方法

• 根据业务id做shardKey(取模或者hash, 或者某类算法)分表

• 根据时间分表(年月日相关)

• 分表冗余表(路由表)

前2种一般都有用到。这里说一下第三种
有时按第一种分表，数据变得难以查询，比如订单表，假定表结包含如下字段

orderId 订单id
uid 用户id
money 订单金额
itemid 商品id

如果存储是按照格式，会发现，如果用户来查询自己的订单，就比较难查询。
这时需要再存储一个对应关，简称路由表，按uid来分表，存储orderId

最优分表方法

其实没有什么最优方法，只有适合的才是最好的。

但是对于分表的的情况，如是数据有冷热之分，比如只查询最近的，一个月前的几乎不会查询到，则需要根据时间更佳，如果担心分月单表压力大，可能再根据uid来分一次，不会随着时间，表里面的数量膨胀到最终爆炸。

数据库分表是解决单表海量数据的查询性能问题。

有些表是没有冷热之分，比如商品表，这个时候就需要分库了，解决单库并发访问压力, 一个不行，多来几个。