[[427290]]

前兩天在朋友圈，我發(fā)了個(gè)小感慨：當(dāng)執(zhí)行 DELETE時(shí)，你心慌不慌?

沒想到大家的內(nèi)心戲，都挺豐富的。

老實(shí)講，俺也一樣。不僅僅是執(zhí)行 DELETE 心里會(huì)咯噔下，多幾次確認(rèn)，哪怕是 INSERT，UPDATE， 甚至是 SELECT， 只要是在生產(chǎn)環(huán)境做的操作，都難免心里會(huì)有些緊張。

那有朋友說了，為什么執(zhí)行 SELECT，心里都會(huì)緊張呢。這里面其實(shí) 有個(gè)小故事的

那年，公司剛上 BO(BusinessObjects),SAP 的一款BI工具。這款工具，最出色是它的 Universe 組件。它就是 OLAP 元引擎。負(fù)責(zé)了從業(yè)務(wù)邏輯視圖到物理底層存儲(chǔ)視圖的轉(zhuǎn)換。

只要 Universe 設(shè)計(jì)的好，自助BI是完全可行的一條路。

但正因?yàn)?，Universe 設(shè)計(jì)得太過于重型，押寶押的大，它在事務(wù)隔離上并沒有做的很出色。經(jīng)常導(dǎo)致一條經(jīng)Universe編譯轉(zhuǎn)換后的SQL， 會(huì)堵塞其他進(jìn)程。

恰恰那一次堵塞，是我造成的。當(dāng)我把Universe編譯后的SQL拿出來一查，居然用了readcommitted 隔離級(jí)別。做過數(shù)據(jù)倉庫的朋友都知道，OLAP 的查詢，可能會(huì)橫跨幾個(gè)時(shí)間段，比如3個(gè)月，5個(gè)月，甚至12個(gè)月更久。

如此巨大的隨機(jī)訪問，給數(shù)據(jù)庫服務(wù)器的壓力，尤其是CPU，IO壓力，一定是巨大的。再加上長(zhǎng)事務(wù)的鎖表，因此阻塞其他進(jìn)程，就沒有懸念了。

老板連用了三段大寫的警告：Never pull suchhuge data on Production!!!

自此，我對(duì) Universe 自動(dòng)生成的 SQL就多了個(gè)心眼，每次都檢查，甚至對(duì) SELECT 語句，也產(chǎn)生莫名的敬畏。即時(shí)查詢，我一定是先設(shè)置隔離級(jí)別，再執(zhí)行。

你們看，SELECT都如此重要，更別說 INSERT/UPDATE/DELETE了。

那怎么緩解執(zhí)行時(shí)的那種焦慮感呢?畢竟就我個(gè)人而已，焦慮緊張時(shí)，我會(huì)胃疼

朋友們紛紛給出自己的解決方法：

• - 備份
• - 多次檢查
• - 先走一遍UAT，再上生產(chǎn)
• - 寫好辭職報(bào)告，隨時(shí)走人
• - 千萬別申請(qǐng)生產(chǎn)的DML權(quán)限
• - 壯起膽，閉好眼，干就完了

除了少數(shù)朋友，是來搞氣氛的，其他的建議都不錯(cuò)。

比如，對(duì)小數(shù)據(jù)量的表，做備份;多檢查幾遍 where 條件;先在開發(fā)環(huán)境做測(cè)試，再去生產(chǎn)環(huán)境執(zhí)行，等等。

經(jīng)過實(shí)踐，我覺得保護(hù)好自己的胃(當(dāng)然你可能是腸子，或者是肝膽之類的，畢竟每個(gè)人應(yīng)對(duì)緊張的反應(yīng)不同)，除了少吃，就是要養(yǎng)成好的SQL操作習(xí)慣：

• 對(duì)條件確認(rèn)二遍以上，第一遍看語法，第二遍看邏輯
• 寫好測(cè)試邏輯，來驗(yàn)證執(zhí)行后的結(jié)果
• 對(duì)執(zhí)行腳本做雙重驗(yàn)證，即由另一個(gè)隊(duì)友幫你檢查
• 先在開發(fā)環(huán)境做測(cè)試
• 不要隨機(jī)在生產(chǎn)環(huán)境執(zhí)行更新腳本，定一個(gè)數(shù)據(jù)維護(hù)窗口，比如晚上12點(diǎn)以后
• 需要即時(shí)更新的數(shù)據(jù)，一定加好事務(wù)控制，先執(zhí)行再驗(yàn)證，結(jié)果正確，再提交
• 了解你所用數(shù)據(jù)庫的備份機(jī)制，如果沒有分鐘級(jí)日志備份，申請(qǐng)加上