從 Oracle/DB2 遷移到 MySQL 必知的 5 大差異與坑點

背景

企業級應用常用 Oracle/DB2，遷移至免費 MySQL 時，除語法差異外，仍有架構層面的限制需提前評估。

一、外鍵僅支援數字類型

MySQL 要求外鍵欄位必須為數字類型。若邏輯主鍵含業務字母（如 ORD-2024-001），無法直接作外鍵。
後果：

• 只能用物理主鍵（自增 ID）作外鍵。
• 跨環境遷移數據時，必須保持物理主鍵一致，否則關聯斷裂；若生產環境已存在相同 ID，極易衝突。
• 許多團隊乾脆不建外鍵，犧牲完整性換取遷移靈活性。

二、單表僅能有一個 DEFAULT CURRENT_TIMESTAMP 欄位

同一張表中，create_time 與 update_time 不能同時設 DEFAULT CURRENT_TIMESTAMP。
解決：應用層寫入時顯式賦值，或使用觸發器維護 update_time。

三、TIMESTAMP 精度僅到秒

MySQL 5.6 前 TIMESTAMP 無毫秒支援。若業務需毫秒級，改用 BIGINT 存儲 Unix 毫秒時間戳，或升級至 5.6.4+ 使用 DATETIME(3)/TIMESTAMP(3)。

四、視圖 WHERE 子句不可包含子查詢

-- 失敗
CREATE VIEW v AS SELECT * FROM A WHERE a.x = (SELECT b.x FROM B WHERE ...);

-- 解決 1：改用 JOIN
CREATE VIEW v AS SELECT A.* FROM A JOIN B ON A.x = B.x WHERE ...;

-- 解決 2：子查詢前移至 SELECT 列表
CREATE VIEW v AS SELECT A.*, (SELECT b.x FROM B WHERE ...) AS b_x FROM A;

五、子查詢未做算法優化（執行 N 次）

Oracle 會將非相關子查詢提取為常量，僅執行一次；MySQL 5.6 前對於 WHERE a.x = (SELECT ...)，外層每行皆執行一次子查詢（N = 外層行數）。
禁用子查詢，改用 JOIN 或拆分為兩次查詢。

總結建議

• 遷移前做完整兼容性測試。
• 外鍵策略改為應用層維護或僅用物理鍵。
• 時間精度欄位統一改 BIGINT 或 DATETIME(3)。
• 視圖與複雜查詢優先改寫為 JOIN。