这是一个简单的数据生产导入的故事，原本故事情节应该是这样的：数据整理-->测试验证-->生产发布-->生产验证，然后就是各回各家，所以这本来应该是一个平淡的故事，然而实际却变成了如下情节：数据整理-->测试验证-->生产发布-->生产验证-->校验失败(预期数据未导入)-->问题排查-->解决问题-->生产发布-->生产验证-->校验问题（大部分数据是正确的，少部分数据不正确）-->问题排查（当时未能排查出原因，但能判断出异常与生产原有的几条异常数据有关）-->异常数据删除sql编写-->测试校验-->生产发布-->生产校验-->重新导入删除部分数据（异常数据这次直接排除，没包括在导入范围）-->部分异常数据请示领导修正-->修正Sql准备-->测试校验-->生产发布-->修正数据对应数据导入-->生产校验!
你以为到这里就结束了?NO NO NO，故事怎么可能就这么结束，因为这批数据导入有对应的其它业务，还需要执行该部分业务，最终确认后才能各回各家，结果发现，坑爹的数据库数据是修正了，但因为程序采用了Redis，异常数据还在Redis中，所以还要在Redis中删除该部分异常数据，还好程序部分对此有处理，直接删除没导致程序功能异常，至此本次发布才算结束，但此时也已经是凌晨0点了，这真是一个悲剧的故事……
首先需要介绍下本次导入的猪脚，一个预先写好，且已经发布至生产的存储过程，另外该猪脚所在场景是MySql，其大致代码精简后如下
1 DROP PROCEDURE IF EXISTS `usp_SadEvent`; 2 DELIMITER $$ 3 CREATE PROCEDURE `usp_SadEvent` 4 ( 5 IN identityNo VARCHAR(20), 6 IN uName VARCHAR(15), 7 IN cAmount LONG 8 ) 9 label_at_start:10 BEGIN11 12 SELECT @uid := id FROM `user`13 WHERE identity_no=identityNo AND NAME=uName;14 15 IF @uid IS NULL THEN16 select identityNo,uName,0 ret;17 LEAVE label_at_start;18 END IF;19 update account set balance=balance+cAmount where uid=@uid;20 select identityNo,uN
