?數據庫信創替換已經是很多企業必須面對或者正在面對的問題，而且對于很多企業來說已經不僅是找幾套不太重要的小系統替換一下試試的問題了。對于核心系統的數據庫替代來說問題不大，企業可以投入大量的資金、人力和時間來認真做這件事。反而是大量大型的，關鍵系統的替代不那么容易。因為這些系統的替代一方面還是存在一定難度，另外一方面這些系統如果出問題，還是會對企業的業務有所影響的，而更討厭的是，這樣的系統數量很多，如果都按照核心系統那么投資來干，地主家也干不起。

不知道是不是因為這個原因，做信創數據庫替代的企業領導十分喜歡聽到數據庫廠商提出“平替”這個概念，數據庫廠商也投其所好，說自己的產品能夠“平替”Oracle。久而久之很多企業的不太懂數據庫的管理者們就認為數據庫平替不是一件很難的事情了。我甚至遇到過一個企業的領導提出用RDS MYSQL “平替” Oracle，他認為Oracle和MySQL的SQL都基本上符合SQL 1999的標準，沒理由RDS替不了Oracle。

互聯網企業一直兜售把業務回歸應用來釋放數據庫，從而降低對系統對數據庫的要求。實際上極少數傳統企業的IT部門能夠真正地學會互聯網企業的研發技巧，實際上里面暗藏的一些東西互聯網企業們并沒有向客戶說清楚，那就是這個邏輯背后是對研發的數倍成本的投入，以及企業被軟件開發商的深度綁定。我曾經遇到過一個企業，他們順應甲方領導的思路，把應用系統從Oracle遷移到阿里云RDS MYSQL上，用了幾十個RDS數據庫替換以前的一個Oracle數據庫，為此他們針對這套系統專門開發了一個分庫分表的數據庫路由中間層。我和他們交流的時候問他們為什么要費時費力做這些事情，弄得不好這個項目可能會做虧了。他看著我笑了笑說：“現在吃點苦是值得的，通過這個項目，我們的研發能力提高了一大截。從另外一個角度來看，我敢說這個系統上線的時候，就是甲方離不開我們的時候了，錢不一定都賺在一時”。我想這個哥們從自己企業的角度來考慮這件事，肯定是沒錯的，但是如果甲方的領導聽到這句話會不會脖子后面冒涼風啊。

事實上企業在做大量的數據庫“平替”的時候，并沒有給應用改造和系統遷移留下多少經費，因此“平替”工作僅僅從應用兼容性來考慮就可以了，對于大多數系統來說平替后雖然慢了一些，但是還可以忍受。實在忍受不了的，再做些優化就可以了。大不了把這些問題遺留給運維，讓運維慢慢去解決好了。

不過對于核心系統或者次核心系統來說就沒那么簡單了，企業的決策者不能只是用“平替”這兩個字來對待了。如果不能在數據庫遷移替換時做足功課，那么將會是后患無窮的。比如說我們要把一個系統中的Oracle數據庫替換成基于PG的國產數據庫。如果國產數據庫做了一些Oracle數據庫語法兼容的工作，那么數據庫遷移替換工作會十分順利。甚至有些國產數據庫連PL/SQL的兼容性都很好，那樣情況下，遷移就更順利了。不過遷移完成后，大量的性能問題就冒出來了。

實際上做數據庫遷移的時候不僅僅要考慮兼容性，還要考慮二者之間的一些技術差異，要想辦法彌補國產數據庫的缺陷。比如對于PG數據庫來說，一些WHERE 條件帶or的SQL，如果以前Oracle上的執行計劃使用HASH JOIN效果很好，到了PG或者PG兼容的國產數據庫上，就只能走NESTED LOOP了。如果JOIN的表數據量很大，返回的結果集也很大，那么遷移時就必須對SQL進行改寫，否則遷移后的性能必然是無法接受的。此類SQL數量不多，如果在遷移之時做些測試，企業很容易就能梳理出來，在遷移時把這些SQL改寫好，那么遷移工作也就順利多了。

除此之外，我們還需要充分利用開源或者國產數據庫的優勢能力。還是以Oracle向PG或PG兼容的國產數據庫遷移。PG數據庫的索引種類比Oracle要豐富得多，如果選用得當，那將會事半功倍。這時候如果應用開發人員能夠配合DBA進行索引的優化設計，將會讓遷移工作更加順利。另外如果我們的某些數據的寫入和訪問帶有時序特性的，那么遷移到PG的時候直接用timescaledb的表來存放，設計好自動分區的策略和老數據壓縮的策略，那么這部分的數據訪問效率也會大大的提高。

在數據庫遷移替代工作中，能夠“平替”肯定會大大節約遷移的成本，但是我們不能因為“平替”能力的存在而放棄優化工作，否則就會為今后的長期應用與運維埋下一株邪惡的毒草。