前两天系统的一张明细表的主键字段超出了限制范围，引发了一次生产事故。由于是底层服务使用的表，导致公司多个业务线系统无法使用，属于比较重大的生产事故，分享给大家，避免出现此类低级又重大的生产问题。
奋力写bug.png
事故反馈
首先反馈出异常的是服务的告警机制，告警群中出现大量MySQL异常告警：
告警群.png
然后一线业务使用方在工作群中反馈系统不可用，然后我们赶快紧急排查并解决问题。你懂的，在你排查解决问题的过程中各个相关的同事都会过来问候你一下：产品经理、上级领导、运营、其它服务调用方....此时，你面不改色，镇定自若，其实内心(手动狗头)...
事故原因
导致此次线上事故的原因是系统的一张老表(很早的一张表)的主键是int类型，表中数据存储的数据量(行数)达到了int值的上限：2147483647。你可以想象到这个表有多大：上百GB！
你可能会觉得这种问题好low啊！你说还债也好，报应也罢，我们就当一次日后吹牛逼的话题吧。针对此次事故，重要的是我们解决问题的过程以及从中获取的经验
解决方案
方案1
删除表中的旧数据，设置表的主键自增从0开始，此方案沟通后不行。原因：
- 生产数据不能随便删除，可能有未知隐患
- 表中数据量太大，这张表日增数据量近百万级，从几百G的大表中删除百万数据(需够一天使用)，这个操作将会消耗大量的数据库实例的资源，进而影响其它业务，不可接受
方案2
把表的主键类型由int改为bigint，对应的代码model由Integer改为Long。此处可能是大家有些着急吧，犯了一个流程性的问题：我们开发认为代码层面方案没问题，在热火朝天的修改，结果表结构的变更工单提交给DBA审批，不通过，表数据量太大，变更表结构极其耗时，可能小时级，方案废弃
方案3
创建一张新表，结构和原表一样(只是把主键类型换为bigint)，主键自增从2300000000开始（为了和旧表数据区分），修改业务代码：
- 代码中，新数据写入到新建的表中
- 代码中查数据，从新表和老表中一起查询，合并返回。之所以新旧表一起查询，是因为事故发生时有的业务已经产生过明细数据，然后又被业务人员重新操作，新数据存在新表中
最终采用此方案，修复上线，问题解决。
方案后续处理
- 后续将旧表的数据同步到新表中，恢复单表查询
- 表数据归档
复盘反思
- 数据库表的主键建议采用bigint类型(一般性规约，除非是简单的配置表用int)
- 对老系统，可以定期巡查相关数据表(有告警最好)，提早发现遗留问题，提前解决
- 处理紧急问题，思路很重要，不能盲目修改
