資料庫之淚第四章節

      上次說到的場景7和8都還是有意識要關聯的。但是也有直接select * from a,b 後面什麼都不帶的，雖然執行時間一樣慢，但是輸出效果和意識不一樣。這種真的應該拉出去打一頓。我真的見到過這種引起故障。相比較來說，資料庫安全出問題（極少，不是沒有），硬體故障（更加少，當今硬體技術起步就很高）。而這種SQL引起的不穩定因素幾乎天天有，而且不止一次。從管理學的二八定律來說，精力傾斜應該放在哪裡呢？

   說到這裡有時候又來了一些不明真相的質疑。多方質疑資料庫。（這裡的資料庫是指核心交易資料庫OLTP）

   質疑1：資料庫也不行嘛。一個SQL就能把資料庫搞死。是的。有的時候真的一句話就可以搞當機。因為如果執行了讀幾個TB甚至幾百個TB的資料，資料庫要發出指令CPU和IO全部調動起來，至於要花多久那不好說了。可能幾個小時，也可能幾個星期。這個過程中整個計算機幾乎已經是無響應狀態了。資料庫底層是物理學和數學。如果做出了違反這兩門基礎科學的常識，那麼不是資料庫的問題。是常識問題。

   質疑2：資料庫也不行嘛。這個不讓做，那麼不允許。任何產品都有使用說明書，這些就是使用規範。比如手機說明書中就說不要放到火裡面。同樣SQL也有規範，這種規範不僅僅是如何寫，還有如何寫的好。據說Oracle官方的這個文件2500頁。我是沒見過，我也是聽說的。

   質疑3：資料庫也不行嘛。刪除一個檔案就起不來了？這點上可以理解為在windows的system32中刪除一個檔案（如果可以刪除的話），重啟一下windows也起不來一樣的道理。就像人一樣少了一個重要器官可能也活不了了。之所以資料庫起不來是因為日誌檔案、資料庫檔案、控制檔案等所有檔案的檢查點要一致，如果不一致就是問題，為了防止在錯誤道路上越走越遠，所以不能繼續工作。先解決問題。

一個表上的id1存在A檔案上，本來和另外一個表的id1存在B檔案上關聯的。現在B檔案被刪除了。整個邏輯都不對了，怎麼繼續走下去呢？

   質疑4：資料庫也不行嘛。不能隨時擴充套件。不是不能擴充套件，是不太好擴充套件。因為CAP的一致性原理。在P的前提下，C和A只能滿足一個。在這個理論模型沒有突破之前，一致性就是限制擴充套件的。NoSQL沒有強一致性所以NoSQL不會作為核心交易系統的資料庫。當然現在通過一主多從，以及Oracle RAC等架構是可以擴充套件的。因為大家系統的負荷主要來自於讀，極個別比如阿里雙11的資料庫讀寫都是會迎來高峰的。

   質疑5：資料庫也不行嘛。這點併發就不行了？你看看別人雙11.是的。人家雙11用的是什麼硬體，中小企業用的是什麼硬體？這是大廠的硬實力。大廠的開發可以把程式做到極致，百度春晚的開發甚至在2個位元組上看看能不能優化成1個位元組。支付寶和微信，把業務邏輯做到了極簡。大廠又有很好的規範，禁止犯低階錯誤。比如不會併發出報表，餘額不是把微信10年的收支sum一下得出。這些都支援高併發的軟實力。

   質疑6：資料庫也不行嘛。就不能跳過這個錯誤繼續嗎？問題是真的不行啊。我賬戶有10元錢，別人轉給我1000元。現在有1010元。本來我買一個300元的東西是可以的。但是由於異常這個1000的日誌丟了。沒傳過來或者由於故障跳過去了，最終沒有應用到資料庫日誌中去，最後賬戶就還是10元，這個買300的就買不了。邏輯上和實際不符。再比如說雙向複製。不過用什麼CDC工具都要面對這個問題。 我們假設 AB兩個中心。 有業務要使用A的資料（比如是信用卡）您在上海刷卡。 您夫人用你的副卡在北京出差刷卡。其實是一個卡，一個額度。 你連線A 她連線B 。你說這兩個同時刷卡（非常極端，當然資料庫斷電也是極端不是嘛。就是鑽牛角尖，極端） 好，這個時候你說兩個資料庫怎麼保證不突破額度？可以隨便跳過嗎？  其實如果說資料不重要可以跳過，那麼其實這個系統好像也不重要。反之如果資料一丁點也不能容忍錯誤，那麼這個系統應該是比較重要的。比如金融、支付、證券。這些都不是兒戲，關係到社會民生。

   以前做公安系統面對警方要求的需求，我們會盡力懟回去。儘管市場、銷售找領導壓我們，也不做。因為反科學。最終甲方都能接受我專業的說法，最終放棄了不合理的想法。其實遇到不懂技術的，真的是把脆弱的生命往牆上撞。資料庫基於數學和物理學。違反自然科學的事情，不是資料庫做不到，是現階段科學技術達不到。