這是一個簡單的數(shù)據(jù)生產(chǎn)導(dǎo)入的故事,原本故事情節(jié)應(yīng)該是這樣的:數(shù)據(jù)整理-->測試驗證-->生產(chǎn)發(fā)布-->生產(chǎn)驗證,然后就是各回各家,所以這本來應(yīng)該是一個平淡的故事,然而實際卻變成了如下情節(jié):數(shù)據(jù)整理-->測試驗證-->生產(chǎn)發(fā)布-->生產(chǎn)驗證-->校驗失敗(預(yù)期數(shù)據(jù)未導(dǎo)入)-->問題排查-->解決問題-->生產(chǎn)發(fā)布-->生產(chǎn)驗證-->校驗問題(大部分?jǐn)?shù)據(jù)是正確的,少部分?jǐn)?shù)據(jù)不正確)-->問題排查(當(dāng)時未能排查出原因,但能判斷出異常與生產(chǎn)原有的幾條異常數(shù)據(jù)有關(guān))-->異常數(shù)據(jù)刪除sql編寫-->測試校驗-->生產(chǎn)發(fā)布-->生產(chǎn)校驗-->重新導(dǎo)入刪除部分?jǐn)?shù)據(jù)(異常數(shù)據(jù)這次直接排除,沒包括在導(dǎo)入范圍)-->部分異常數(shù)據(jù)請示領(lǐng)導(dǎo)修正-->修正Sql準(zhǔn)備-->測試校驗-->生產(chǎn)發(fā)布-->修正數(shù)據(jù)對應(yīng)數(shù)據(jù)導(dǎo)入-->生產(chǎn)校驗!

你以為到這里就結(jié)束了?NO NO NO,故事怎么可能就這么結(jié)束,因為這批數(shù)據(jù)導(dǎo)入有對應(yīng)的其它業(yè)務(wù),還需要執(zhí)行該部分業(yè)務(wù),最終確認(rèn)后才能各回各家,結(jié)果發(fā)現(xiàn),坑爹的數(shù)據(jù)庫數(shù)據(jù)是修正了,但因為程序采用了Redis,異常數(shù)據(jù)還在Redis中,所以還要在Redis中刪除該部分異常數(shù)據(jù),還好程序部分對此有處理,直接刪除沒導(dǎo)致程序功能異常,至此本次發(fā)布才算結(jié)束,但此時也已經(jīng)是凌晨0點了,這真是一個悲劇的故事……

首先需要介紹下本次導(dǎo)入的豬腳,一個預(yù)先寫好,且已經(jīng)發(fā)布至生產(chǎn)的存儲過程,另外該豬腳所在場景是MySql,其大致代碼精簡后如下

大學(xué)生就業(yè)培訓(xùn),高中生培訓(xùn),在職人員轉(zhuǎn)行培訓(xùn),企業(yè)團訓(xù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