记一次mysql数据丢失后逐步修复的过程

背景：

    近期做了一个话务管理的功能，就是调用大唐电信的接口完成与客户的电话沟通，并将通话信息记录在数据表中。该功能已经上线了两个多月，一直运行正常，但是前天我自己在查询生产数据时发现了一个问题：我们的通话记录中很多字段的值都为null。而这些字段应该是在挂断电话时大唐回调我们的接口更新到我们的数据表中的，所以一开始我怀疑大唐在某些情况下挂断电话是不走回调的，就与大唐的同事沟通，他们的反馈是任何情况下的电话挂断都会回调我们的接口。按说此时我本应该意识到是我们的接口在更新数据时出现了问题，但我竟然没有第一时间去测试我们的接口，而是继续忙其他的事情，直到一天后其他部门的同事反应电话打通之后没有查询到通话记录，此时我才开始测试自己的接口，发现是大唐在回调我们的接口时某个字段的值变长了，我们的数据表的长度不足以存储变长后的数据导致在UPDATE时失败了。关于此，我应该做自我检讨：

    1、遇到生产问题时的敏感度不够强，既然是生产问题，就应该第一时间解决，不应该在发现了问题还置之不理，因为生产问题是最重要的问题，很可能造成严重的事故；

    2、在遇到问题时应该首先考虑是不是自己的问题并进行测试，在测试完之后再决定是应该修正自己还是去询问别人，而不应该首先想到或许是别人的问题，就像这一次我应该首先测试一下自己的接口，这样也可以避免一些无效的沟通，当然这次大唐修改接口的返回值没有知会我方也有点不地道；

    3、自己编码的习惯问题：不要盲目的相信自己，任何人的代码都有可能在不同的时间点出现问题，所以要记得把代码中可能出现异常的地方给出前台提示或打印后台日志，方便进行跟踪，尤其是在SQL的INSERT和UPDATE操作的时候&#x