當(dāng)執(zhí)行 Delete 時，你心慌了
前兩天在朋友圈，我發(fā)了個小感慨：當(dāng)執(zhí)行 DELETE時，你心慌不慌?
沒想到大家的內(nèi)心戲，都挺豐富的。
老實講，俺也一樣。不僅僅是執(zhí)行 DELETE 心里會咯噔下，多幾次確認(rèn)，哪怕是 INSERT，UPDATE， 甚至是 SELECT， 只要是在生產(chǎn)環(huán)境做的操作，都難免心里會有些緊張。
那有朋友說了，為什么執(zhí)行 SELECT，心里都會緊張呢。這里面其實 有個小故事的
那年，公司剛上 BO(BusinessObjects),SAP 的一款BI工具。這款工具，最出色是它的 Universe 組件。它就是 OLAP 元引擎。負(fù)責(zé)了從業(yè)務(wù)邏輯視圖到物理底層存儲視圖的轉(zhuǎn)換。
只要 Universe 設(shè)計的好，自助BI是完全可行的一條路。
但正因為，Universe 設(shè)計得太過于重型，押寶押的大，它在事務(wù)隔離上并沒有做的很出色。經(jīng)常導(dǎo)致一條經(jīng)Universe編譯轉(zhuǎn)換后的SQL， 會堵塞其他進(jìn)程。
恰恰那一次堵塞，是我造成的。當(dāng)我把Universe編譯后的SQL拿出來一查，居然用了readcommitted 隔離級別。做過數(shù)據(jù)倉庫的朋友都知道，OLAP 的查詢，可能會橫跨幾個時間段，比如3個月，5個月，甚至12個月更久。
如此巨大的隨機(jī)訪問，給數(shù)據(jù)庫服務(wù)器的壓力，尤其是CPU，IO壓力，一定是巨大的。再加上長事務(wù)的鎖表，因此阻塞其他進(jìn)程，就沒有懸念了。
老板連用了三段大寫的警告：Never pull suchhuge data on Production!!!
自此，我對 Universe 自動生成的 SQL就多了個心眼，每次都檢查，甚至對 SELECT 語句，也產(chǎn)生莫名的敬畏。即時查詢，我一定是先設(shè)置隔離級別，再執(zhí)行。
你們看，SELECT都如此重要，更別說 INSERT/UPDATE/DELETE了。
那怎么緩解執(zhí)行時的那種焦慮感呢?畢竟就我個人而已，焦慮緊張時，我會胃疼
朋友們紛紛給出自己的解決方法：
- - 備份
- - 多次檢查
- - 先走一遍UAT，再上生產(chǎn)
- - 寫好辭職報告，隨時走人
- - 千萬別申請生產(chǎn)的DML權(quán)限
- - 壯起膽，閉好眼，干就完了
除了少數(shù)朋友，是來搞氣氛的，其他的建議都不錯。
比如，對小數(shù)據(jù)量的表，做備份;多檢查幾遍 where 條件;先在開發(fā)環(huán)境做測試，再去生產(chǎn)環(huán)境執(zhí)行，等等。
經(jīng)過實踐，我覺得保護(hù)好自己的胃(當(dāng)然你可能是腸子，或者是肝膽之類的，畢竟每個人應(yīng)對緊張的反應(yīng)不同)，除了少吃，就是要養(yǎng)成好的SQL操作習(xí)慣：
- 對條件確認(rèn)二遍以上，第一遍看語法，第二遍看邏輯
- 寫好測試邏輯，來驗證執(zhí)行后的結(jié)果
- 對執(zhí)行腳本做雙重驗證，即由另一個隊友幫你檢查
- 先在開發(fā)環(huán)境做測試
- 不要隨機(jī)在生產(chǎn)環(huán)境執(zhí)行更新腳本，定一個數(shù)據(jù)維護(hù)窗口，比如晚上12點以后
- 需要即時更新的數(shù)據(jù)，一定加好事務(wù)控制，先執(zhí)行再驗證，結(jié)果正確，再提交
- 了解你所用數(shù)據(jù)庫的備份機(jī)制，如果沒有分鐘級日志備份，申請加上
