資料照搬完了，真正的難題才開始：那些跑了十年的 T-SQL，V9R4C019 打算怎麼接

（本文回顧的內容出自 2026 年 9 月 11 日發表於掘金的技術長文，作者為「一隻牛博」。文中的遷移經驗與程式碼示例均以該文為本。）

做過資料庫遷移的人，多半有同一段心路：資料表搬遷跑完那一晚，大家鬆一口氣，以為工程結束了大半。真正的麻煩在隔天才浮上來。倉庫裡那些跑了很多年的 T-SQL 批處理，才是讓開發團隊睡不著的部分。

這篇在開發者社羣流傳的文章，講的就是這一段。場景很具體：庫存日結用 MERGE 合併資料，帳戶變更用 OUTPUT 寫審計紀錄，經營報表裡還有窗口函數和 PIVOT。這幾類程式碼如果全要重寫，後面跟著變的就不只是 SQL 本身，還有異常處理、受影響行數、審計日誌和報表欄位。一句話總結：改的不只是語法，是一整條業務邏輯的接縫。

先別急著算檔案數，先做「語義對位」

原文提出一個很有畫面的說法，把遷移看成一次「語義對位」。不急著按檔案數量估工期，而是先找出最常用、最容易牽動業務的語法區塊，看目標版本能不能保留原來的表達方式。

這個思路背後是對現實的承認。SQL Server 的程式碼有明顯的語法習慣：TOP、表變數、@name 區域變數、GO 批次結束符、PRINT、MERGE，這些東西在預存程序裡通常成組出現。資料遷過去之後再逐條處理，很快就會變成一份沒有邊界的改造清單，工時估算整個失準。

目標庫這次選的是 KingbaseES V9R4C019 的 SQL Server 相容版。文章特別強調，物件評估、腳本轉換和應用回歸要在同一個版本上完成，不要評估用一版、驗收又換一版。金倉官方的《SQL Server 至 KingbaseES 遷移指南》把資料類型、SQL 語法、PL/MSSQL、用戶端介面和遷移工具放在同一條路徑上，順序是：先確認程式碼能不能保留，再處理少數確實與應用邏輯相關的差異。

MERGE 保住了日結任務的原有結構

看一個典型場景。庫存日結通常先把當天變動寫入中間表，再按商品和倉庫合併到庫存主表。原本的 T-SQL 是一條 MERGE：匹配到舊紀錄就更新數量，沒匹配到就新增。

V9R4C019 對 MERGE 語法的支援，讓這段程式碼可以原樣保留結構：匹配條件、更新表達式和新增欄位仍然放在同一個語句裡。原文指出，如果把這段拆成「先查詢、再判斷、最後 UPDATE 或 INSERT」，事務中會多出一段不必要的分支，回歸測試也要重新設計。保留 MERGE 之後，驗收可以繼續圍繞批次號、庫存量這些原本就在盯的指標展開，不用另起爐竈。

文章還給了一段驗收查詢的範例：從中間表和主表各自彙總，核對同一批增量是否全部落庫，包括批次行數、數量加總與主表當前餘量。這種驗收方式的價值在於，它驗的是業務結果，而非語法轉換是否成功。翻譯成更直白的話：報表數字對得上，遷移才算數。

DML OUTPUT 讓審計鏈不用換寫法

金融、會員和供應鏈系統裡，有一種很常見的寫法：更新資料的同時，用 DML OUTPUT 從 deleted 和 inserted 兩個臨時結果集直接取值，寫入審計表。這種寫法的好處是原子性，更新和留痕在同一個語句裡完成。

如果目標資料庫不支援這個語法，後果是什麼？原文的形容很精準：你會被迫把一次原子的更新，改成應用層的「先讀後寫」。這不只是多寫幾行程式碼的問題，中間任何一步失敗，都可能出現資料改了、審計沒記到的縫隙。對需要留痕合規的系統來說，這條縫就是風險本身。V9R4C019 對這類語法的支援，價值正在於把這條審計鏈原樣接住。

相容不是萬靈丹，但能讓改造清單有邊界

回到更大的圖景。V9R4C019 這一版針對的高頻場景，除了 MERGE 和 DML OUTPUT，還包括窗口函數、PIVOT/UNPIVOT 和 LIKE 萬用字元。這些都是報表與批次處理裡最常見、也最容易牽一髮動全身的語法塊。

值得留意的是原文的態度：它沒有把相容能力講成「全部不用改」。相反地，它反覆強調要先評估、後處理差異，把真正需要動的程式碼圈出來。這其實是存量系統遷移最務實的一種姿態：與其承諾零修改，不如讓改造清單變得有邊界、可估算、可驗收。

對正在評估資料庫遷移的團隊來說，這篇長文提供的經驗可以壓縮成幾個動作：選定目標版本後全程不換版；先盤點高頻語法塊而非清點檔案；能保留的語義結構盡量保留，讓回歸測試沿用原本的業務指標；最後，驗收盯的是報表數字和審計紀錄，不是轉換工具跑完與否。

資料搬完只是把家具運到新家。真正決定住得舒不舒服的，是那些用了十年的水管線路，能不能原樣接上。V9R4C019 這次補強的相容能力，處理的正是「接線」這一段。至於每個團隊的線路有多複雜，還是得各自蹲下來慢慢理，這部分，任何版本都代替不了。