我這里沒有現(xiàn)成的項目正文、關(guān)鍵詞和摘要可用只能根據(jù)這個標(biāo)題本身把一線遷移過程中實(shí)際會遇到的事講清楚。做過多套從國外商用數(shù)據(jù)庫往國產(chǎn)數(shù)據(jù)庫遷的活之后最大的感受是遷移本身并不難難的是遷移之前沒人告訴你的那些隱性成本和看起來能跑但實(shí)際是錯的改寫。這篇文章就圍繞工具選型、參數(shù)配置、性能調(diào)優(yōu)三條主線展開我把踩過的坑和修正過程一起寫出來希望能幫后面接手這類活兒的人少走幾趟彎路。1. 遷移前先搞清楚這次遷移真正難在哪很多人拿到遷移任務(wù)后第一反應(yīng)是找工具其實(shí)這是順序錯了。工具解決的是怎么搬但真正決定項目成敗的是搬過去能不能跑、跑得對不對這屬于兼容性評估的范疇。我在多個項目里發(fā)現(xiàn)將近一半的延期和返工都出在遷移前的評估階段而不是遷移執(zhí)行階段。1.1 兼容性評估別只測SQL要連數(shù)據(jù)行為一起測先說兼容性評估。很多團(tuán)隊的做法是拿業(yè)務(wù)SQL清單到目標(biāo)庫上跑一遍能跑通就算兼容跑不通就交給開發(fā)改。這種評估方式太粗糙了因為數(shù)據(jù)庫遷移里最隱蔽的問題根本不是SQL語法而是數(shù)據(jù)行為的差異。舉個例子Oracle里空字符串和NULL是兩回事你敢寫WHERE col Oracle會把空串轉(zhuǎn)成NULL所以這個條件永遠(yuǎn)不成立。KingbaseES早期的兼容模式里不一定保持這個行為。再比如NUMBER類型在Oracle里可以存整數(shù)也可以存小數(shù)精度范圍極大遷到KingbaseES如果用NUMERIC那問題不大但如果評估時沒注意類型映射工具給自動映射成了INT那小數(shù)位直接被截斷上線后賬單金額差幾毛錢這種事都能發(fā)生。所以做兼容性評估時我建議至少準(zhǔn)備三層檢查語法層現(xiàn)有應(yīng)用里的SQL能不能在目標(biāo)庫跑通工具一般能覆蓋語義層同樣的SQL在兩邊返回結(jié)果是否一致特別是空值、排序、聚合、類型轉(zhuǎn)換這些基礎(chǔ)行為數(shù)據(jù)層存量數(shù)據(jù)里的邊界值、超長字符串、特殊字符能否無損落庫語義層和數(shù)據(jù)層往往需要編寫專門的對比腳本把同一批數(shù)據(jù)分別在兩個庫上跑同一套查詢邏輯然后做結(jié)果集比對。這個環(huán)節(jié)不要偷懶也不要只看抽樣結(jié)果能全量比對就全量比對。1.2 盤點(diǎn)對象時最容易漏掉的那幾類對象盤點(diǎn)也是遷移前的重要環(huán)節(jié)。建表結(jié)構(gòu)、索引、視圖這些大家基本不會漏容易漏的是以下幾類序列Oracle應(yīng)用里SEQ.NEXTVAL隨處可見遷到KingbaseES如果不處理序列應(yīng)用一跑就直接報錯觸發(fā)器用于審計、默認(rèn)值填充、級聯(lián)操作的觸發(fā)器遷移時常常被忽略導(dǎo)致業(yè)務(wù)邏輯靜默缺失包和存儲過程Oracle的PL/SQL包里有變量、游標(biāo)、異常處理KingbaseES的兼容模式能處理一部分但復(fù)雜包經(jīng)常需要手工改寫物化視圖及其刷新機(jī)制如果源端有物化視圖并且業(yè)務(wù)依賴定期刷新目標(biāo)端也得有對應(yīng)的實(shí)現(xiàn)和調(diào)度同義詞很多老系統(tǒng)里同義詞用得很多這也屬于需要顯式遷移的對象我之前接手過一個模擬系統(tǒng)光序列就有一百多個分布在幾十個表上。遷移工具自動處理了一部分但有幾張表的主鍵用的是TRIGGER SEQUENCE的方式在插入前用觸發(fā)器取序列值工具沒有識別出這個模式。結(jié)果數(shù)據(jù)導(dǎo)進(jìn)去之后新插入的記錄主鍵直接沖突調(diào)試了整整一天才定位到是觸發(fā)器少建了幾個。這種問題在評估階段如果細(xì)盤對象是完全可以提前發(fā)現(xiàn)的。1.3 停機(jī)窗口和數(shù)據(jù)量決定遷移策略評估完兼容性之后就要確定遷移策略。策略主要取決于兩個因素停機(jī)窗口和數(shù)據(jù)量。停機(jī)窗口很短比如兩小時以內(nèi)數(shù)據(jù)量又大幾百GB那基本只能靠存量數(shù)據(jù)全量導(dǎo)出導(dǎo)入加增量數(shù)據(jù)同步兩條腿走路。增量同步是技術(shù)難度最高的部分好在KingbaseES在這塊有配套的同步工具可以對接日志需要提前聯(lián)調(diào)。停機(jī)窗口比較充裕數(shù)據(jù)量也就幾十GB那更簡單直接停應(yīng)用、導(dǎo)數(shù)據(jù)、校驗、啟動一條龍下來就完事了。另外還需要考慮網(wǎng)絡(luò)帶寬。源端和目標(biāo)端如果不在同一機(jī)房中間帶寬只有百兆那幾百GB的數(shù)據(jù)怎么壓縮、怎么多線程傳輸都要提前設(shè)計。千萬別等遷移當(dāng)天再測網(wǎng)速那是給自己埋雷。2. 工具選型先分清你要的是搬數(shù)據(jù)還是搬業(yè)務(wù)工具選型這塊我的建議是先想清楚一個核心問題你是要搬數(shù)據(jù)還是搬業(yè)務(wù)這兩個訴求對應(yīng)的工具路徑完全不一樣。市面上很多宣傳都說自己能做到一鍵遷移、業(yè)務(wù)無感但實(shí)際用下來能自動化處理90%的常規(guī)對象就已經(jīng)是優(yōu)秀水平剩下10%的硬骨頭基本都得靠人寫腳本硬啃。2.1 數(shù)據(jù)遷移工具怎么選批量數(shù)據(jù)的搬運(yùn)工如果目標(biāo)只是把數(shù)據(jù)從一個庫搬到另一個庫那么核心關(guān)注點(diǎn)是這批數(shù)據(jù)有多重、數(shù)據(jù)要不要轉(zhuǎn)換、停在窗口內(nèi)的限制是什么。在真實(shí)項目中我常用的方案分三類通用ETL工具、數(shù)據(jù)庫原生邏輯備份工具、以及數(shù)據(jù)同步類工具。三類工具各有各的適用場景工具類型典型代表優(yōu)點(diǎn)局限性通用ETL/同步框架DataX、Kettle等數(shù)據(jù)源適配廣、可視化、可定制轉(zhuǎn)換邏輯大批量表結(jié)構(gòu)遷移仍需配合DDL轉(zhuǎn)換性能調(diào)參需要細(xì)致數(shù)據(jù)庫原生邏輯導(dǎo)出導(dǎo)入expdp/impdp輔助分析、目標(biāo)庫自帶導(dǎo)出工具、copy命令等類型映射準(zhǔn)確、性能較高、適合同生態(tài)遷移跨庫遷移時DDL、存儲過程等對象仍需額外轉(zhuǎn)換數(shù)據(jù)同步工具基于日志的增量同步工具這里指數(shù)據(jù)庫廠商配套的同步組件停機(jī)窗口可以縮到很短、支持增量追平環(huán)境要求較嚴(yán)苛、偶爾有斷點(diǎn)續(xù)傳問題這里我不建議一上來就選最重的同步方案。如果數(shù)據(jù)量不大、窗口夠用全量邏輯導(dǎo)出導(dǎo)入又快又穩(wěn)出問題時排查鏈路也短。同步工具適合的是那種必須把停機(jī)時間壓縮到分鐘級的苛刻場景。2.2 結(jié)構(gòu)遷移工具能幫你生成80%的DDL和PL/SQL結(jié)構(gòu)遷移比數(shù)據(jù)遷移要難得多特別是Oracle里的PL/SQL、包、函數(shù)、視圖、觸發(fā)器。好在絕大多數(shù)國產(chǎn)庫包括KingbaseES在內(nèi)生態(tài)里都有專門的遷移評估和轉(zhuǎn)換工具這類工具通常做的事情是掃描Oracle下的全部對象按類型分類列出自動完成一部分DDL和PL/SQL的語法轉(zhuǎn)換輸出轉(zhuǎn)換報告標(biāo)注哪些對象轉(zhuǎn)換成功、哪些需要人工處理這類工具輸出的轉(zhuǎn)換成功率有沒有參考價值有但別全信。我曾經(jīng)在一個項目上拿一套復(fù)雜的業(yè)務(wù)包做測試工具報的轉(zhuǎn)換成功率不到80%剩下的全靠人工補(bǔ)但另一套比較規(guī)范的系統(tǒng)工具幾乎全部自動處理完了。所以工具的自動化程度和源系統(tǒng)本身的寫法規(guī)不規(guī)范高度相關(guān)。這里有一個很實(shí)用的經(jīng)驗如果在評估階段發(fā)現(xiàn)源系統(tǒng)里大量使用了一些較為復(fù)雜的高級特性比如自治事務(wù)、動態(tài)SQL、帶OUT參數(shù)的存儲過程調(diào)用那你基本就要做好人工改造至少兩三周的心理準(zhǔn)備。千萬不要只看工具報告上的百分比。2.3 人工改造怎么拆解才高效人工改造是最耗時但也最不可跳過的環(huán)節(jié)。高效拆解的關(guān)鍵是把改造任務(wù)分類按難度排序不要眉毛胡子一把抓。結(jié)合我的實(shí)戰(zhàn)改造清單一般這么拆純語法改寫NVL改COALESCE、SYSDATE改CURRENT_TIMESTAMP、||或CONCAT語義核對。這類工作量大但機(jī)械適合交給工具批量處理人工抽查驗證。邏輯等價改寫ROWNUM分頁改LIMIT、外連接寫法()改標(biāo)準(zhǔn)LEFT JOIN。這類需要改的人理解兩邊語義差異適合由熟悉SQL的工程師處理逐個走讀。結(jié)構(gòu)性改造存儲過程里的包狀態(tài)、批量收集、動態(tài)SQL重構(gòu)這類往往是性能殺手需要結(jié)合應(yīng)用調(diào)用關(guān)系一起考慮建議由資深工程師負(fù)責(zé)。另外改造時一定要保留一份源SQL與目標(biāo)SQL對照清單每條SQL都要能追溯到業(yè)務(wù)含義否則后面聯(lián)調(diào)時根本沒法定位問題。我見過有些團(tuán)隊改完就不管了上線后一條SQL結(jié)果不對找了半天也定位不到是哪個應(yīng)用觸發(fā)出來的就是吃了沒有對應(yīng)關(guān)系的虧。3. 參數(shù)配置遷移之前把坑提前踩平參數(shù)配置是避坑指南里的重量級章節(jié)。很多人覺得參數(shù)配置就是改幾個內(nèi)存大小但實(shí)際涉及的層面很多從數(shù)據(jù)庫初始化參數(shù)到客戶端連接串再到遷移任務(wù)自身的并發(fā)度每個參數(shù)都可能成為壓垮駱駝的最后一根稻草。3.1 實(shí)例參數(shù)按目標(biāo)負(fù)載而不是按源庫配置先說數(shù)據(jù)庫實(shí)例參數(shù)。KingbaseES的內(nèi)核與開源數(shù)據(jù)庫生態(tài)有緊密關(guān)系很多經(jīng)典參數(shù)可以借鑒參考但不要照搬Oracle那套思維。常見需要調(diào)整的關(guān)鍵參數(shù)包括shared_buffers共享緩沖區(qū)如果服務(wù)器內(nèi)存充足可以按物理內(nèi)存的約1/4來設(shè)置但要留意操作系統(tǒng)緩存配合。設(shè)置太小熱點(diǎn)數(shù)據(jù)頻繁落盤性能直線下降。work_mem工作內(nèi)存排序、哈希操作會用到的內(nèi)存。設(shè)置太大會導(dǎo)致并發(fā)場景下內(nèi)存溢出設(shè)置太小又會讓排序落盤。建議結(jié)合業(yè)務(wù)實(shí)際并發(fā)量來評估不要拍腦袋。maintenance_work_mem維護(hù)操作內(nèi)存創(chuàng)建索引、收集統(tǒng)計信息這類操作使用。這個參數(shù)在遷移建索引階段影響巨大調(diào)大一些能顯著縮短操作時間。checkpoint相關(guān)大量數(shù)據(jù)導(dǎo)入時檢查點(diǎn)觸發(fā)頻繁會導(dǎo)致落盤抖動。適度調(diào)大檢查點(diǎn)間隔和緩沖區(qū)平穩(wěn)完成導(dǎo)入再說。WAL相關(guān)參數(shù)導(dǎo)入場景下可以放松一些持久化策略加快寫入但前提是能接受導(dǎo)入過程中異常斷電可能丟失數(shù)據(jù)的風(fēng)險。遷移階段可以臨時調(diào)業(yè)務(wù)上線后要恢復(fù)為穩(wěn)妥配置。還有個參數(shù)別忽略連接數(shù)上限。遷移時往往會有多個工具和腳本同時連庫如果連接數(shù)設(shè)得太小很多任務(wù)會直接連不上看起來像網(wǎng)絡(luò)故障。3.2 連接串和驅(qū)動參數(shù)被忽略的隱形因素連接串和驅(qū)動這塊很多問題不是參數(shù)本身錯了而是版本不匹配導(dǎo)致的行為差異。我們在遷移時經(jīng)常遇到這樣的情況JDBC驅(qū)動版本過低對目標(biāo)庫某些類型支持不完整讀出來的字符串長度不對或者日期格式解析異常。建議用官方推薦的驅(qū)動分支并且讓應(yīng)用和遷移腳本統(tǒng)一驅(qū)動管理。prepareThreshold或等價機(jī)制值得重點(diǎn)關(guān)注。默認(rèn)情況下來自某些驅(qū)動的語句在執(zhí)行多次時會做服務(wù)端預(yù)編譯好處是性能更好但壞處是如果應(yīng)用里習(xí)慣用字符串拼接SQL的方式服務(wù)端預(yù)編譯空間的占用和解析開銷可能會成為瓶頸。必要時需要把預(yù)編譯閾值調(diào)低或關(guān)閉。還有fetchSize抓取行數(shù)。很多做數(shù)據(jù)比對或大批量導(dǎo)出的腳本默認(rèn)抓取方式會一次性把結(jié)果集全部拉進(jìn)內(nèi)存數(shù)據(jù)一大就直接內(nèi)存溢出。顯式設(shè)置合理的抓取行數(shù)比如每次抓取1000行能解決很多奇怪的內(nèi)存問題。這一點(diǎn)在從Oracle遷到KingbaseES后尤其明顯因為兩邊驅(qū)動對游標(biāo)和結(jié)果集的默認(rèn)處理行為并不一致。3.3 遷移任務(wù)自身的參數(shù)并行度不是越大越好做數(shù)據(jù)導(dǎo)入時很多人會犯一個誤區(qū)并行度拉滿。常見的做法是同時開幾十個線程導(dǎo)數(shù)據(jù)結(jié)果目標(biāo)庫的鎖競爭、檢查點(diǎn)壓力、日志壓力全部拉滿整體速度反而比8個線程還慢。我的經(jīng)驗是并行度先按CPU核數(shù)的60%-70%起步再觀察監(jiān)控如果IO等待不高、CPU還有余量再逐步加大批量大小單事務(wù)批量行數(shù)以500到2000行為宜太大會導(dǎo)致內(nèi)存開銷高、回滾段壓力大太小則提交次數(shù)過多日志寫入頻繁導(dǎo)入順序先導(dǎo)父表再導(dǎo)子表或者先禁用約束導(dǎo)完再重建。如果按原樣直接導(dǎo)外鍵約束會讓導(dǎo)入速度大打折扣另外為遷移準(zhǔn)備的賬號權(quán)限要給足但又不能超出必要范圍。我遇到過遷移賬號沒有目標(biāo)庫序列的修改權(quán)限導(dǎo)致自動生成序列的起始值不對導(dǎo)入數(shù)據(jù)后序列又從1開始結(jié)果主鍵沖突。這種小坑調(diào)試起來非常耗神。4. 處理Oracle專有寫法從能跑到跑得對的距離這一章主要講Oracle里那些特有寫法遷到KingbaseES后容易出現(xiàn)語法不報錯但結(jié)果不對或語法報錯但不知道換成什么的案例。每一條我都盡量把背景和改寫思路一起講清楚。4.1 dual、sysdate、rownum這些老朋友dual 表。Oracle里SELECT SYSDATE FROM DUAL這類寫法非常普遍。KingbaseES在兼容模式下內(nèi)置了對dual的支持所以大部分場景直接能跑。但要注意不是所有帶dual的語句都能原樣落地如果語句里用了Oracle特有的函數(shù)問題會轉(zhuǎn)移到函數(shù)本身。建議評估階段集中搜索FROM DUAL逐個確認(rèn)關(guān)聯(lián)的函數(shù)都被目標(biāo)庫支持。SYSDATE。Oracle的SYSDATE精度是秒級別而KingbaseES推薦用CURRENT_TIMESTAMP也能工作但返回精度更高。數(shù)據(jù)插入時如果字段是DATE這種精度差異通常不會造成問題但如果業(yè)務(wù)里做了時間差運(yùn)算可能在邊界上產(chǎn)生差異。更穩(wěn)妥的方案是統(tǒng)一改成CURRENT_TIMESTAMP并做一輪結(jié)果驗證別讓線上出現(xiàn)時間多了0.001秒這種糾纏不清的case。ROWNUM。ROWNUM在Oracle里既用于分頁也用于限制返回行數(shù)。KingbaseES里常規(guī)替代是LIMIT。這里有一個最常見的坑Oracle里ROWNUM 1是取第一行但ROWNUM 1是永遠(yuǎn)不返回行有人機(jī)械改成LIMIT 1后把原本想看有沒有數(shù)據(jù)的邏輯變成了取第一行業(yè)務(wù)語義不同。-- Oracle: SELECT * FROM (SELECT * FROM t ORDER BY id DESC) WHERE ROWNUM 10; -- KingbaseES: SELECT * FROM t ORDER BY id DESC LIMIT 10;這類改寫看起來簡單但漏掉外部嵌套、錯寫排序字段的事情時有發(fā)生一定要用真實(shí)數(shù)據(jù)前后對比。4.2 序列與自增列不檢查起始值就等于埋雷序列遷移是主鍵沖突的第一大來源。Oracle里序列通常是獨(dú)立對象應(yīng)用在插入前顯式調(diào)用NEXTVAL。遷到KingbaseES后你面臨兩個選擇保留獨(dú)立序列對象改寫調(diào)用方式改成自增列含identity或其他自增機(jī)制然后改造應(yīng)用去掉顯式調(diào)用我個人的建議如果應(yīng)用里調(diào)用序列的地方非常多改成自增列反而是一項大工程因為所有插入語句都要動。不如保留序列對象只把調(diào)用方式做適配。但不管選哪種都必須手動校準(zhǔn)序列的起始值讓它大于當(dāng)前表里的最大ID。補(bǔ)救辦法是在遷移后執(zhí)行序列設(shè)置類操作。比如SELECT setval(seq_xxx, (SELECT max(id) FROM table_xxx));這個動作一定要寫在遷移步驟清單里而且要放在數(shù)據(jù)導(dǎo)入之后執(zhí)行否則就會出現(xiàn)數(shù)據(jù)導(dǎo)完了、序列還在原地踏步的悲劇。4.3 空表、LOB、分區(qū)表隱蔽的數(shù)據(jù)完整性殺手空表。Oracle的某些版本里空表在遷移工具掃描時是不占空間的如果遷移工具依賴數(shù)據(jù)字典里的段信息可能漏掉空表結(jié)構(gòu)。結(jié)果就是表沒建出來業(yè)務(wù)一跑就報表或視圖不存在。處理方式是遷移前先對空表做一次建表語句生成確保結(jié)構(gòu)遷移階段全部覆蓋。LOB字段。CLOB、BLOB遷移的常見問題是碎片化、性能差和編碼差異。尤其是超大CLOB如果工具默認(rèn)一次性讀入內(nèi)存極易OOM。建議分批讀取、寫入。分區(qū)表。Oracle的分區(qū)策略多種多樣范圍分區(qū)、列表分區(qū)、哈希分區(qū)都有。KingbaseES支持的分區(qū)種類也很多但映射關(guān)系不是一一對應(yīng)的。遷移時要重點(diǎn)檢查分區(qū)鍵類型和邊界值定義避免邊界數(shù)據(jù)進(jìn)入錯誤分區(qū)。-- Oracle 范圍分區(qū)示例 CREATE TABLE sale ( id NUMBER, sale_date DATE ) PARTITION BY RANGE (sale_date) ( PARTITION p2023 VALUES LESS THAN (TO_DATE(2024-01-01,YYYY-MM-DD)), PARTITION p2024 VALUES LESS THAN (TO_DATE(2025-01-01,YYYY-MM-DD)) ); -- KingbaseES 適配寫法 CREATE TABLE sale ( id numeric, sale_date date ) PARTITION BY RANGE (sale_date); CREATE TABLE sale_p2023 PARTITION OF sale FOR VALUES FROM (2023-01-01) TO (2024-01-01); CREATE TABLE sale_p2024 PARTITION OF sale FOR VALUES FROM (2024-01-01) TO (2025-01-01);注意邊界語義差異Oracle用LESS THAN分區(qū)的上邊界是不包含的而KingbaseES的分區(qū)范圍寫法默認(rèn)也是上邊界不包含這點(diǎn)還好。但如果分區(qū)鍵是時間戳類型邊界值兩邊的寫法精度不一致可能出現(xiàn)微妙的差異需要仔細(xì)對齊。4.4 PL/SQL改寫不要只在語法上做文章PL/SQL包和存儲過程遷移是最耗時的一環(huán)。改寫的關(guān)鍵不只是語法還包括變量類型、游標(biāo)、隱式游標(biāo)屬性、異常處理、動態(tài)SQL等側(cè)面。比較典型的改寫點(diǎn)%TYPE和%ROWTYPE目標(biāo)庫是否支持對應(yīng)的屬性聲明通常支持但嵌套在包變量里時要看兼容程度FORALL和BULK COLLECT批量處理語法能否直接兼容如果不能需要改成循環(huán)加集合類型的處理方式性能上要注意別退化太嚴(yán)重自治事務(wù)Oracle里的PRAGMA AUTONOMOUS_TRANSACTION用于在事務(wù)中隔離一段獨(dú)立提交。KingbaseES對自治事務(wù)有一定支持但語義邊界要仔細(xì)驗證特別是嵌套和異?；貪L的場景動態(tài)SQLEXECUTE IMMEDIATE在目標(biāo)庫里通常也有對應(yīng)寫法但綁定變量的類型推斷有所不同偶爾會出現(xiàn)運(yùn)行時類型轉(zhuǎn)換錯誤一個很重要的建議PL/SQL改造完成后不要只在單元層面驗證。要把它放進(jìn)完整的應(yīng)用調(diào)用鏈里做集成測試因為很多包之間共享了全局變量或游標(biāo)狀態(tài)分開測試看不出問題合在一起就跑出臟數(shù)據(jù)。5. 性能調(diào)優(yōu)從慢到不能忍到符合預(yù)期遷移完成后性能調(diào)優(yōu)是另一個大塊工作。很多團(tuán)隊覺得數(shù)據(jù)導(dǎo)過去就完事了結(jié)果業(yè)務(wù)一上線原來200毫秒的查詢變成5秒才發(fā)現(xiàn)性能問題才剛開始。性能調(diào)優(yōu)要分階段做不要一上來就亂改SQL。5.1 先看執(zhí)行計劃再談優(yōu)化遇到慢查詢第一步永遠(yuǎn)是看執(zhí)行計劃而不是憑經(jīng)驗加索引。KingbaseES支持EXPLAIN ANALYZE可以查看真實(shí)執(zhí)行信息和耗時分布。拿到執(zhí)行計劃后重點(diǎn)關(guān)注幾個信號Seq Scan順序掃描大表說明缺索引或者統(tǒng)計信息沒更新Nested Loop 循環(huán)嵌套如果內(nèi)外表基數(shù)都很大可能要改成哈希連接排序操作內(nèi)存溢出說明work_mem設(shè)置不足或者查詢本身需要簡化行數(shù)估算偏差大基本是統(tǒng)計信息陳舊先收集統(tǒng)計信息再觀察我見過一個典型案例某查詢在Oracle上秒回遷到KingbaseES后十幾秒。執(zhí)行計劃顯示大表與小表連接時選擇了嵌套循環(huán)因為統(tǒng)計信息沒有更新優(yōu)化器估錯了小表的行數(shù)。手動執(zhí)行一次統(tǒng)計信息收集后執(zhí)行計劃切換成了哈希連接查詢降到幾百毫秒。這種情況先不要改SQL把統(tǒng)計信息做準(zhǔn)就已經(jīng)解決一大半問題。5.2 統(tǒng)計信息、索引和外鍵索引遷移后第一件事就是收集統(tǒng)計信息。不管是導(dǎo)數(shù)據(jù)還是導(dǎo)入后重建索引統(tǒng)計信息都可能是舊值或缺失。用高采樣率把全部表統(tǒng)計一遍比任何調(diào)優(yōu)都更基礎(chǔ)。索引層面有幾個容易忽略的點(diǎn)外鍵列必須有索引Oracle里如果外鍵列缺索引某些DML比如刪除父表記錄可能觸發(fā)全表鎖或全表掃描。KingbaseES沒有自動幫你在外鍵列建索引的機(jī)制遷移后要手工補(bǔ)函數(shù)索引Oracle里WHERE UPPER(col) ABC可以走函數(shù)索引目標(biāo)庫也支持表達(dá)式索引但遷移工具不一定能自動轉(zhuǎn)換這類定義部分索引帶WHERE條件的索引如果源庫有對應(yīng)機(jī)制可以遷移過來有助于減小索引體積-- 例補(bǔ)外鍵索引 CREATE INDEX idx_order_user ON orders(user_id); -- 例表達(dá)式索引 CREATE INDEX idx_user_name_upper ON users(UPPER(user_name));索引也不是越多越好。很多系統(tǒng)從Oracle遷過來原庫里的索引九成都是有效的但偶爾有些冗余索引只會拖慢導(dǎo)入速度。遷移時先把必要的唯一索引、主鍵索引建好業(yè)務(wù)驗證之后再根據(jù)慢查詢反饋補(bǔ)二級索引這是比較穩(wěn)健的順序。5.3 查詢改寫OR改UNION、IN改EXISTS這些老套路KingbaseES優(yōu)化器能力已經(jīng)相當(dāng)不錯但還是有一些查詢模式容易踩坑。以下幾個改寫方向是實(shí)戰(zhàn)中高頻使用的大表上的OR多個條件用OR連接時優(yōu)化器有時很難選擇合適的索引改寫為UNION ALL或拆成多條SQL往往更快IN子查詢數(shù)據(jù)量大如果子查詢返回行數(shù)很多且外表也大改寫成EXISTS或顯式的JOIN可能更高效。這個不要機(jī)械套用要實(shí)測深分頁LIMIT 100000, 20這種深分頁需要掃描并丟棄前面大量行有足夠索引支撐時可以考慮密鑰集分頁子查詢拉平有些嵌套子查詢在執(zhí)行計劃里被拉平效果更好手動改寫有時反而更差一切以執(zhí)行計劃為準(zhǔn)這里再強(qiáng)調(diào)一次改寫參考可以看但一定用數(shù)據(jù)說話。同樣的SQL在這套數(shù)據(jù)量下走A方案快換一套數(shù)據(jù)分布可能B方案更好。團(tuán)隊里應(yīng)該形成每個改寫都必須跑EXPLAIN和實(shí)際耗時對比的約定。5.4 大批量導(dǎo)入性能從小時級到分鐘級數(shù)據(jù)導(dǎo)入慢是遷移現(xiàn)場最常見的焦慮源之一。優(yōu)化導(dǎo)入速度通常從幾個方向同時下手禁用或延遲索引導(dǎo)入前先刪除非唯一索引導(dǎo)完再重建。這個辦法對幾百GB的表能省出大量時間調(diào)整導(dǎo)入事務(wù)粒度不要每行一個事務(wù)也不要超大事務(wù)一把梭。批量提交搭配合理的事務(wù)大小既保證進(jìn)度可控也讓數(shù)據(jù)異常時可定位并行寫多表如果表之間沒有外鍵約束依賴可以分表并行導(dǎo)入。有依賴關(guān)系的表按拓?fù)渑判驕p少約束檢查的開銷避開高峰遷移盡量放在系統(tǒng)低峰期避免跟正常業(yè)務(wù)爭搶IO和CPU我記憶里有一次遷移一個大批量歷史表幾千萬行。第一次傻乎乎開著大量索引導(dǎo)跑了一個多小時后來改成先刪非唯一索引、調(diào)大一批導(dǎo)入量、再并行導(dǎo)四張關(guān)聯(lián)表最后不到20分鐘導(dǎo)完建索引又花了5分鐘。這個對比足夠說明導(dǎo)入策略對最終耗時有決定性影響。另外導(dǎo)入過程中要持續(xù)觀察計數(shù)器和系統(tǒng)負(fù)載。如果發(fā)現(xiàn)磁盤IO已經(jīng)打滿并行度再高也沒用反倒可能拖垮整個實(shí)例。這時候?qū)幙赏Ｏ聛碚{(diào)整也別硬跑到底。5.5 數(shù)據(jù)校驗上線前的最后一道防線數(shù)據(jù)校驗不解決性能問題但它解決的是性能再高但數(shù)據(jù)錯了等于白干的問題。校驗分幾個層次總量校驗統(tǒng)計每個表的行數(shù)、關(guān)鍵字段的sum值兩側(cè)對比抽樣校驗按主鍵抽樣比對單個字段尤其關(guān)注字符型字段尾空格、數(shù)值精度、日期格式邏輯校驗針對業(yè)務(wù)關(guān)鍵口徑比如訂單金額匯總、用戶狀態(tài)分布編寫校驗SQL在兩側(cè)分別跑對比結(jié)果應(yīng)用回歸最有效的一層直接用測試賬號跑業(yè)務(wù)流程看有沒有功能報錯和數(shù)據(jù)異常校驗?zāi)_本建議在遷移前就寫好別等數(shù)據(jù)導(dǎo)完再臨時寫。臨時寫的腳本又慢又容易漏而且校驗SQL本身也要在兩個庫上跑兩邊語法未必完全一致提前驗證校驗?zāi)_本是很有必要的。6. 上線切換和回退把退路留好心里不慌遷移項目最后一步是切換上線。切換方案里必須包含三個要素切換步驟、驗證步驟、回退步驟。很多人準(zhǔn)備工作做得很細(xì)但回退方案寫得草率結(jié)果真出問題時手忙腳亂。我的建議是切換當(dāng)天按這個順序走停止應(yīng)用寫入確認(rèn)源庫不再有新數(shù)據(jù)產(chǎn)生執(zhí)行最后一輪增量同步或補(bǔ)數(shù)記錄源庫和目標(biāo)庫的校驗快照應(yīng)用連接串切換到目標(biāo)庫跑核心業(yè)務(wù)冒煙用例啟動完整業(yè)務(wù)觀察監(jiān)控回退方案要提前演練。7. 聊聊我自己的感受做了幾個遷移項目之后我最大的體會是遷移這件事真正難的從來不是搬數(shù)據(jù)這個動作而是如何在搬完之后讓業(yè)務(wù)感覺什么都沒發(fā)生。工具選型選得再好參數(shù)調(diào)得再順最后決定成敗的還是那些反復(fù)校驗、逐條對照、不斷追問為什么兩邊結(jié)果不一樣的笨功夫。如果你正在負(fù)責(zé)類似的遷移建議務(wù)必要留出充足的緩沖時間。工具評估三成的時間對象盤點(diǎn)兩成改造四成切換和驗證兩成這樣比例下來項目不會太慌。真要說有什么金句值得記住那就是別相信任何一次性的自動遷移結(jié)果人工驗證和回歸測試永遠(yuǎn)不能省。