前两天系统的一张明细表的主键字段超出了限制范围，引发了一次生产事故。由于是底层服务使用的表，导致公司多个业务线系统无法使用，属于比较重大的生产事故，分享给大家，避免出现此类低级又重大的生产问题。

奋力写bug.png

事故反馈

首先反馈出异常的是服务的告警机制，告警群中出现大量MySQL异常告警：

告警群.png

然后一线业务使用方在工作群中反馈系统不可用，然后我们赶快紧急排查并解决问题。你懂的，在你排查解决问题的过程中各个相关的同事都会过来问候你一下：产品经理、上级领导、运营、其它服务调用方....此时，你面不改色，镇定自若，其实内心(手动狗头)...

事故原因

导致此次线上事故的原因是系统的一张老表(很早的一张表)的主键是int类型，表中数据存储的数据量(行数)达到了int值的上限：2147483647。你可以想象到这个表有多大：上百GB！
你可能会觉得这种问题好low啊！你说还债也好，报应也罢，我们就当一次日后吹牛逼的话题吧。针对此次事故，重要的是我们解决问题的过程以及从中获取的经验

解决方案

方案1
删除表中的旧数据，设置表的主键自增从0开始，此方案沟通后不行。原因：

1. 生产数据不能随便删除，可能有未知隐患
2. 表中数据量太大，这张表日增数据量近百万级，从几百G的大表中删除百万数据(需够一天使用)，这个操作将会消耗大量的数据库实例的资源，进而影响其它业务，不可接受

方案2
把表的主键类型由int改为bigint，对应的代码model由Integer改为Long。此处可能是大家有些着急吧，犯了一个流程性的问题：我们开发认为代码层面方案没问题，在热火朝天的修改，结果表结构的变更工单提交给DBA审批，不通过，表数据量太大，变更表结构极其耗时，可能小时级，方案废弃

方案3
创建一张新表，结构和原表一样(只是把主键类型换为bigint)，主键自增从2300000000开始（为了和旧表数据区分），修改业务代码：

1. 代码中，新数据写入到新建的表中
2. 代码中查数据，从新表和老表中一起查询，合并返回。之所以新旧表一起查询，是因为事故发生时有的业务已经产生过明细数据，然后又被业务人员重新操作，新数据存在新表中

最终采用此方案，修复上线，问题解决。

方案后续处理

1. 后续将旧表的数据同步到新表中，恢复单表查询
2. 表数据归档

复盘反思

1. 数据库表的主键建议采用bigint类型(一般性规约，除非是简单的配置表用int)
2. 对老系统，可以定期巡查相关数据表(有告警最好)，提早发现遗留问题，提前解决
3. 处理紧急问题，思路很重要，不能盲目修改