專案背景與遷移必要性
專案初期採用 SQL Server，後因成本、跨平台或生態系統考量，決定遷移至 MySQL。資料遷移不僅是表結構轉換，更涉及資料類型映射、存儲過程重寫、SQL 語法調整等複雜環節。本文整理類型差異、常見陷阱及三種主流遷移方案，助你平滑過渡。
一、SQL Server 與 MySQL 常用資料類型對照表
（圖片展示兩類資料庫的類型對應關係，建議遷移前逐一核對）
二、遷移前必須注意的三大陷阱
1. 唯一索引對 NULL 的處理差異
- SQL Server：唯一索引欄位僅允許一個 NULL。
- MySQL / Oracle：唯一索引欄位允許多個 NULL。
- 影響：若原表依賴「多 NULL 唯一」業務邏輯，遷移後會報錯，需調整索引或業務代碼。
2. 存儲過程語法差異巨大
T-SQL (SQL Server) 與 MySQL 的程序語言在變數宣告、流程控制、錯誤處理、游標操作等方面差異極大，存儲過程遷移通常是最耗時、最易出錯的環節，建議人工逐行重寫並充分測試。
3. 應用層 SQL 語句需同步修改
程式碼中寫死的 SQL（如分頁、日期函數、字串連接、MERGE 語法等）必須改寫為 MySQL 相容語法，建議集中梳理後統一替換。
三、三種主流遷移方案優劣對比
方案一：SQLyog 圖形化遷移
優點：操作直觀、支援欄位級映射（如 DATETIME→TIMESTAMP）、成功率高。
缺點：速度極慢，百萬級資料表可能需數小時，不適合大數據量場景。
方案二：PowerDesigner 逆向工程 + SSMS 匯出 INSERT 腳本
- 用 PowerDesigner 逆向 SQL Server 產生 ER 圖，正向生成 MySQL 建表腳本（或手動調整 SSMS 匯出的 DDL）。
- 用 SSMS 將各表資料匯出為
INSERT 腳本檔（每表一檔），必要時做字元編碼/轉義處理，再在 MySQL 執行匯入。
優點：可控性強、適合大數據量、可人工優化結構。
缺點：步驟較繁瑣，需熟悉兩側工具。
方案三：MySQL Workbench / Navicat 官方遷移工具
- Workbench 連線 SQL Server 要求帳號具備
VIEW ANY DATABASE 權限，否則無法讀取元資料。
- Navicat 操作邏輯類似 SQLyog，但通常效能略優。
適用場景：中小型資料庫、追求一鍵式遷移的團隊。
遷移檢查清單
- ☐ 所有表結構（主鍵、外鍵、索引、預設值、檢查約束）已在 MySQL 重建
- ☐ 存儲過程、觸發器、視圖、函數已全量改寫並通過單元測試
- ☐ 應用程式 SQL 已適配 MySQL 語法（分頁、鎖提示、系統函數等）
- ☐ 資料完整性驗證（行數、關鍵欄位 checksum、業務抽樣）
- ☐ 效能基準測試（慢查詢、索引使用率、連線池配置）
總結
資料庫遷移是系統工程，而非單純工具操作。建議採用「結構先行、資料跟進、代碼適配、全鏈路驗證」的分階段策略，並預留充足回滾窗口。
