這是一個(gè)簡(jiǎn)單的數(shù)據(jù)生產(chǎn)導(dǎo)入的故事，原本故事情節(jié)應(yīng)該是這樣的：數(shù)據(jù)整理-->測(cè)試驗(yàn)證-->生產(chǎn)發(fā)布-->生產(chǎn)驗(yàn)證，然后就是各回各家，所以這本來應(yīng)該是一個(gè)平淡的故事，然而實(shí)際卻變成了如下情節(jié)：數(shù)據(jù)整理-->測(cè)試驗(yàn)證-->生產(chǎn)發(fā)布-->生產(chǎn)驗(yàn)證-->校驗(yàn)失敗(預(yù)期數(shù)據(jù)未導(dǎo)入)-->問題排查-->解決問題-->生產(chǎn)發(fā)布-->生產(chǎn)驗(yàn)證-->校驗(yàn)問題（大部分?jǐn)?shù)據(jù)是正確的，少部分?jǐn)?shù)據(jù)不正確）-->問題排查（當(dāng)時(shí)未能排查出原因，但能判斷出異常與生產(chǎn)原有的幾條異常數(shù)據(jù)有關(guān)）-->異常數(shù)據(jù)刪除sql編寫-->測(cè)試校驗(yàn)-->生產(chǎn)發(fā)布-->生產(chǎn)校驗(yàn)-->重新導(dǎo)入刪除部分?jǐn)?shù)據(jù)（異常數(shù)據(jù)這次直接排除，沒包括在導(dǎo)入范圍）-->部分異常數(shù)據(jù)請(qǐng)示領(lǐng)導(dǎo)修正-->修正Sql準(zhǔn)備-->測(cè)試校驗(yàn)-->生產(chǎn)發(fā)布-->修正數(shù)據(jù)對(duì)應(yīng)數(shù)據(jù)導(dǎo)入-->生產(chǎn)校驗(yàn)!
你以為到這里就結(jié)束了?NO NO NO，故事怎么可能就這么結(jié)束，因?yàn)檫@批數(shù)據(jù)導(dǎo)入有對(duì)應(yīng)的其它業(yè)務(wù)，還需要執(zhí)行該部分業(yè)務(wù)，最終確認(rèn)后才能各回各家，結(jié)果發(fā)現(xiàn)，坑爹的數(shù)據(jù)庫(kù)數(shù)據(jù)是修正了，但因?yàn)槌绦虿捎昧薘edis，異常數(shù)據(jù)還在Redis中，所以還要在Redis中刪除該部分異常數(shù)據(jù)，還好程序部分對(duì)此有處理，直接刪除沒導(dǎo)致程序功能異常，至此本次發(fā)布才算結(jié)束，但此時(shí)也已經(jīng)是凌晨0點(diǎn)了，這真是一個(gè)悲劇的故事……
首先需要介紹下本次導(dǎo)入的豬腳，一個(gè)預(yù)先寫好，且已經(jīng)發(fā)布至生產(chǎn)的存儲(chǔ)過程，另外該豬腳所在場(chǎng)景是MySql，其大致代碼精簡(jiǎn)后如下
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
