Mysql千万数据级分表设计及实现方案（2）附一致性哈希原理解析

首先，接着上篇博文：Mysql千万数据级分表设计及实现方案已经分析了自增id作分表key和全局服务id（16位）作分表key进行分表的两种设计方案。自增id优势在于简单，直接哈希取模即可分表完成。根据全局服务生成的16位用户id（或订单id）则需关注分表键生成策略，根据生成策略确定取模算法，保证数据尽量均匀分布。另外采取uid还得关注热点用户导致的数据热点问题，若出现热点问题，可针对热点数据做缓存处理，减少某几张表的数据存取压力。

下面根据项目实践来进一步总结分析分库分表设计及落地方案。

一、根据数据年增长量及业务增长量预估，确定分表数

以库中最大数据量作考量，分析如下：

1、交易账单表当前数据量：8kw

2、2017年增长：8kw

根据dba建议考虑分表后单表数据量不超过1kw估算，8kw/16=0.5kw *2年=1kw，若分成16张表可基本满足两年的数据增长。

 二、结合业务，每张表对应crud操作，确定分表key

在选择分表键，有两个点需要重点关注：

1、采用外部键作为分表键

因为一般查询业务都是根据订单id，用户id等具备业务属性key调用交易，选择这些key的好处在于业务线直接传入分表键，无需二次映射操作，直接路由即可。而劣势在于，键的生成策略外部控制，与业务线强耦合，且类型等受制。

对于公司如果提供全局的id生成，且各系统均采取该方式维护，则可以采取外部键。

2、选择自身生成id（pay_id）为分表键

业务线查询业务key（b_U_id|order_id），此时业务线对pay_id是无感知的，与交易交互仅通过业务线id或订单id，则需要：

方案1：考虑先查出分表key后路由（方案：查取缓存、或创建bid-pay_id的映射表）

方案2：根据业务线传入id做一次查询。每次操作多余一次查询，且查询分表在无分表key情况下，依次查。存在效率问题

最终选取2中方案1，建立业务表与分表键的映射表，且映射表同样进行分表，一次业务交互两次路由。

 三、根据业务背景，确定分表方式

垂直拆分

1、常见拆分场景

a). 大字段的垂直切分。单独将大字段建在另外的表中，提高基础表的访问性能，原则上在性能关键的应用中应当避免数据库的大字段

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

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