从单表到分表实现数据平滑迁移

背景

初到新公司接手支付中心系统，发现支付表单表数据量达到了 7 亿多，震惊之余不由的脊背发凉，这个系统运行犹如走钢丝，稍微有点风吹草动就可能造成线上事故，DBA 天天催着要数据迁移，给出大表解决方案，给出排期。

当你担心一件事要出问题，他就一定会出问题，不得不说这墨菲定律真™️准。营销部门搞活动，支付单量激增，客服反应好多用户投诉明明支付成功了，但还是处于支付中状态。打开日志排查原因，就是因为数据库响应慢，支付状态未能更新成功，导致未能及时通知上游系统支付成功结果。（当然支付逻辑也存在问题，这点不在此文讨论范围内）

痛定思痛，分库分表和数据迁移迫在眉睫。

分库？分表？

什么时候需要分库

分库主要是解决并发量大的问题，数据库的连接数是有限的，当读或者写的QPS过高，导致数据库连接数不够时，就需要考虑分库，通过增加数据库实例的方式来增加连接数，从而提升系统的并发性能。

什么时候需要分表

分表主要时应对数据量大的情况，当一个表的数据量过大时，不论是读还是写的性能都会出现明显下降，一张表的数据量最好控制在1000万以内（看硬件性能）。

业务增量分析及容量规划

首先通过计算得到高峰期QPS每秒约50，并发量不算特别高，所以没有必要做分库来分担并发量。

在业务高峰期的月份每日的支付单量约270多万，业务低峰期的月份每日的支付单量约130多万，每年大概的单量为6亿单左右，

按照3到5年的规划&#x