📅【資料修正實戰】當資料庫日期欄位出現亂碼，工程師是怎麼「安全修復」的？

- 2月 13, 2026

一、為什麼資料庫的「日期」會壞掉？

在許多企業系統中，資料庫會長期累積來自不同來源的資料，例如：

自動化機台上傳
第三方系統轉檔
批次程式（Batch Job）
人工補資料

只要其中 任一流程發生例外，就可能出現這種狀況：

日期欄位裡，居然不是日期，而是奇怪的符號或代碼

例如：

不明符號
系統佔位字元
暫存標記

這類問題在系統初期不一定會出錯，但當資料被拿來：

報表分析
排程統計
系統對帳
時，問題就會全面爆發。

二、為什麼不能「直接改掉」錯誤資料？

很多非工程背景的人會直覺想：

「既然這筆資料是錯的，那就直接改掉不就好了？」

但對工程師來說，這是高度危險的行為，原因有三個：

1️⃣ 你不知道「正確值」是什麼

亂改，可能只是把錯誤「換成另一個錯誤」。

2️⃣ 資料之間其實是有關聯的

同一筆業務資料，可能在資料庫中：

出現多次
分散在不同流程、不同站點

3️⃣ 一旦寫入，幾乎無法回復

資料庫不像 Excel 可以按「復原」，
錯一次，可能影響 數年歷史資料。

三、工程師真正的修復思路是什麼？

工程師不會「憑感覺改資料」，而是用邏輯比對。

核心概念只有一句話：

不要修「孤立的錯誤資料」，

而是用「同一筆資料的其他紀錄」來驗證。

四、什麼是「跨流程驗證」？（給完全不懂的人）

假設一個產品會經過多個流程站點：

流程 A
流程 B
流程 C

理論上：

這些流程記錄的是同一批東西
關鍵資訊（例如日期）應該高度相似

但現在發現：

流程	日期欄位
A	❌ 出現亂碼
B	✅ 正常
C	✅ 正常

👉 那工程師會怎麼做？

答案是：

用 B 或 C 的資料，回頭「修正 A」。

五、工程師怎麼確保「修的是對的」？

實務上會分成 三個安全階段。

🔍 第一階段：只看、不改（模擬修正結果）

工程師會先做一件事：

模擬：如果今天真的要修，會被改成什麼？

但這個階段：

❌ 不寫入資料庫
❌ 不影響正式資料
✅ 只產出對照清單

目的只有一個：
👉 讓人「看得懂」即將發生什麼事

🧠 第二階段：設定「可信資料優先順序」

不是每一筆參考資料都一樣可靠。

工程師會事先定義規則，例如：

優先使用「主要流程」的資料
若沒有，再使用「次要流程」
完全排除本身就有異常標記的資料

這樣做的目的是：

避免用「次級錯誤」去修「主要錯誤」

🔒 第三階段：正式修正（一定包在安全機制內）

真正更新資料時，一定會：

使用「可回復機制」
記錄影響筆數
確保只影響「確定有問題的資料」

工程師最怕的不是資料錯，
而是「不小心改到不該改的資料」。

六、為什麼這樣的修法「長期有效」？

這種做法的優點是：

✅ 不依賴人工判斷
✅ 可重複執行
✅ 適用於大量歷史資料
✅ 可寫成標準作業流程（SOP）

也代表：

下次再發生同樣問題，

不需要再人工處理一次。

七、這類問題通常「真正的根因」是什麼？

從工程經驗來看，最常見的原因包含：

上游系統格式不一致
機台或檔案轉換失敗
批次程式沒有做完整驗證
系統用「特殊符號」暫存失敗狀態

所以，資料修正只是止血，
真正的改善，通常還會包含：

載入時就檢查資料合法性
將異常資料隔離而非直接寫入
在源頭就避免亂碼進資料庫

八、結語：資料修正不是改值，而是「證明」

對工程師來說，
資料修正從來不是「把錯的改掉」這麼簡單。

而是：

你必須能解釋：

為什麼這個值是對的。

當你能用「系統內其他紀錄」來證明它，
這個修正才是專業、可追溯、可被信任的。

搜尋此網誌

小小大大學