資料庫 内 “卷” 在 當時

卷， 内卷，目前社會的現狀，每個人都在感受當今社會的内卷，每個人也都在為内卷“添磚加瓦”。換到資料庫本身也身在内“卷” 中， 每個從業者都無法逃避，卷，與被卷。

從XC（兩個簡寫是什麼意思，我也不大敢說），資料庫行業的内卷就開始了，從一個手就可以扒拉幹淨的從業機構，到上百家機構湧現，當然這是好的，終究會有好的JG從其中湧現出來，來分一分，從ORACLE上掉下的一塊塊“肉”，也必然形成競争過度，變成時下的“卷”。

其實有沒有人冷靜的思考一個問題，到底資料庫要做什麼，客戶需要什麼，什麼都有，什麼都能，各種奇葩的要求都能做到，甚至一些聽上去不符合邏輯和理性的需求，都完全肯定，加上各種的QP性的測試，組成了目前“卷”的實質,你能130， 我能170 ，測試的性能和上世紀放衛星一樣的高産，實際的FS估計隻有鬼知道，資料庫的性能在部分資料庫上你要多低，就有多低。

YN呆了幾個月，從熱切的加入，到灰冷的撤出，是在是卷的厲害，不能消受，某些CP就和改裝車一樣，發動機一樣，變速箱一樣，加一個貼膜或者換換輪胎的大小就可以稱為GH之光。

或許ZB都是都是要逐利，這是一個無法改變的本質，時間上不允許有更多的思考和可能走的彎路，剩下的就是拼勁全力“制造”出來，看上去和衆泰保時捷一樣的産品以及各種客戶提出無法回答的Questions.

 有些問題實質如此，如FBS資料庫必然在一定資料量的情況下，無法和DT的資料的性能比拟，2PC方式的送出必然導緻事務送出的時延增加，資料通路節點的切換，很可能導緻業務通路的中斷，系統壓力過大加上拿來就用的高可用，必然會引起某些敏感的資料庫節點的swithover  over over over. TSO 已經成為業界的FBS标準化，有些問題是“胎”裡帶，并不是一時半刻可以快速解決和處理了,可惜在卷的時代，哪裡讓你有時間改正和訴說其中的不易，有的隻有魔術性的測試和比拼誰有更好看的戲法。

經過此事，也算受到真切的教訓，看上去很美的東西，隻可遠觀不可亵玩，不切實際的CP，會在時間的洗禮下，或快或慢的沒有聲音，卷到最後，隻是卷了個寂寞。

。

諒某些簡寫，還是 select * from CP where  SQ like "%模糊%" 的比較好，終究就是講一個“故事”。