说几个大厂分库分表的那点破事。

本文内容预览：

1. 库表会在哪天到达瓶颈？

   1.1 苏宁拼购百万级库表拆分之前
1.2 京东配运平台库表拆分之前
1.3 大众点评订单库拆分之前

   1.4 小结：啥情况需要考虑库表拆分

2. 拆分库表的目的和方案

   2.1 业务数据解耦--垂直拆分
2.2 解决容量和性能压力--水平拆分
2.3 分多少合适

   2.4 怎么分合适

3. 拆分带来新的问题

   分区键/唯一ID/数据迁移/分布式事务等

4. 大厂案例，知识回顾扩展

   4.1 蚂蚁金服的库表路由规则
4.2 大众点评分库分表的数据迁移

   4.3 淘宝万亿级交易订单的存储引擎

Part1 库表会在哪天到达瓶颈？

1.1 苏宁拼购百万级库表拆分之前 [1]

苏宁拼购，苏宁易购旗下的电商App，18年7月累计用户突破3000万。

图片来源于QCon大会PPT

面对千万级日活 + 千万级日新增SKU + 千万级日均订单，拼购的单库每天增长数据超1亿，峰值10万QPS并发，每个月要搞一次数据迁移。

庞大的数据量，对数据库压力和数据运维成本造成了很大的困扰，并且，一旦有一条未命中缓存的SQL，对于整个应用都是灾难级的。

所以，不得不考虑系统的稳定性和长远的业务支撑。

1.2 京东配运平台库表拆分之前 [2]

图片来源于QCon大会PPT

起初，用SQL Server存储，⽀支撑每天10万级别业务量。

扛不住后，采购了企业级Oracle/IBM AIX⼩型机，用 RAC + DataGuard方式，支撑配送所有业务，到百万级别单量。但是这种传统的企业架构，对于复杂多变的业务、昂贵的硬件成本、服务的部署和维护成本等痛点，变得越来越突出。

15年开始，京东配运平台开始按业务对数据库做垂直拆分，将存储容器化，实现了方便的水平扩容、更精细的成本控制、更复杂的业务形态支持.

1.3 大众点评订单库拆分之前 [3]

16年前，点评的订单库已经超200G容量，面对的越来越复杂的查询维度，为实现平稳查询，优化了索引并增加两个从库来分散数据库压力，但仍有很多效率不理想的数据库请求出现。

而随后而来的价格战、大量抢购的活动开展，订单数据库很快难以支撑，只能用限流、消息队列削峰填谷对其进行保护，才能勉强维持日常数据读写需求。

而随着业务模式的增加，原订单模型已经不能满足，如果经常用DDL去建表，建索引对于如此庞大的库表是非常吃力的，发生锁库锁表会直接影响线上服务