從開發角度看資料庫到現在浮躁的心態

    我在給一位原來做開發的朋友演示一個場景的時候，他非常仔細的發現了我講的過程中一個細節。他問到說建立一個組合索引（複合索引），兩個先後關係誰先誰後是不一樣的嗎？能意識到這一點我覺得很不錯。但凡做過資料庫最佳化的人都知道這是有差別的，而在開發視角上絕大部分不知道。這也很正常，在國內大部分公司來說，開發對此知之甚少。

   在Oracle MySQL PG以及一些國產資料庫的群內，大家不管對資料庫有什麼分歧，在開發這裡高度一致。就是開發幾乎沒有資料庫的基礎。昨天和一些原網際網路大廠的朋友吃飯，，我說大廠好點吧？他說大廠也一樣。聽到這裡我心裡平衡多了。

   繼續第一個組合索引前後的問題，我問在開發團隊一般怎麼辦？他說就是單列，誰如果去建立一個組合的，而且最後居然（請注意這裡這個副詞，能用上簡直是撞上大運或者燒了高香了）能用上，大家就會覺得這個人好厲害。哎說到這裡不僅僅為我們們普遍的技術能力嘆息。就這我們國內還200多家國產資料庫呢。開發國產的開發是不是都知道各種事務隔離級別與之對應的鎖的情況？不知道的話你怎麼做下去？

   還要不少開發甚至自己進行資料庫選型，這就更加的不靠譜了。甚至覺得資料庫不夠架構湊。一個資料庫不行多來幾個，一下子PPT就好看了。大多數領導也不懂技術，只是不知道這些領導看不看成本吧。本來一個A資料庫解決了，結果要改成3-5個B資料庫。這裡我本身沒有指明說AB誰好誰不好。資料庫只要用好了（業務場景和資料庫適配都可以）都好，如果不適配，比如用MySQL做ERP就不明智。但是不能說MySQL不好。某個場景大量使用點陣圖索引的，，MySQL沒有點陣圖索引，那就不適配。所以要使用數量來解決問題，不一定能解決。

   不少時候不是數量就一定能替代質量的。有人開玩笑說，人逼急了什麼事情的做的出來？  那你把這道數學題給我做了。 這種場景下不是多來幾差不多水平的人就能解決高難度的問題。現在還是不計成本的浮躁心態太多。

   我本身很反感不解決本質問題，就是讓架構去緩解矛盾，不斷包容。這種都是問題。從前我聽一個朋友說有個公司，就是全表查，但是呢就是不改。最後大量分庫分表。資料庫是白嫖不花錢，但是資料庫伺服器都是花錢的，希望他們看賬單時候也能從容淡定。（當然這看是花的是公司的錢還是自己個人的腰包，我要是創業公司老闆看到這種直接就開罵）。

    有些領導非常厲害，經常拷問：我的使用者量是多少，我們的CPU是多少？使用者量和CPU的比是不是合理？

  一般來說IT部門都是成本部門，要為公司節約成本。不能浪費公司的錢。其實回答這種使用者量和CPU的比，我有個類比方法。就是對比騰訊，這樣的資料大家都相信。現在幾乎每個人都有微信。我們估計10億人使用微信是一定有的。如果使用者和CPU是1比1，那麼騰訊僅僅在微信上就要10億個CPU，這還不算榮耀等。顯然騰訊的技術開發和運維部門不會做的這麼差。我僅僅是打比方。如果是使用者和CPU是10比1，那麼就要1億個CPU。如果一臺伺服器10個CPU，這裡說的都是虛擬機器的CPU不是物理CPU。以此類推吧。想想會有1000萬臺嗎（僅微信）？

   現在不少公司，甚至國內大部分中小企業的資訊化，其實單機就夠。但是一定要拆，又是一個朋友說，不拆不搞微服務我們招不到人。言下之意是不來點虛的，別人看不上，覺得學習不到什麼，或者說人家將來換公司，這裡沒什麼好寫的。其實這就是風氣，（不正之風呀）上週一篇中臺騙局的文章就獲得了10萬多的閱讀，我估計就是太多人意識到了，虛到一定程度泡沫破滅了，要不然不會這樣的。

   學習毛澤東思想和鄧小平理論的課程時候，看到實事求是就選，這是考點。實事求是說起來容易做起來太難了。可能是實事求是沒有賣點，不過做技術的還是別追求這個。我再次說一個朋友告訴我的故事，一個開源軟體的問題，我們國內的幾十號人幹了幾個月沒解決。然後有個外國的專家（其實是一個小夥子），來了一看。幹了幾天解決了。最終的問題還是要靠務實來解決的。

    全文寫的有點雜，請包涵一下。