這兩個月竟然有兩次機會幫客戶從 MySQL 轉到 SQL Server 上，一次負責轉移資料到雲端的 SQL Database 上，另一次負責移轉資料到本地的 SQL Server 上，這兩次我都是用 Microsoft SQL Server Migration Assistant v5.3 for MySQL 來執行移轉任務，轉換的過程中遇到了不少問題，所以特地撰文紀錄，以免日後再次遇到相同的困擾。
其實 MySQL 與 SQL Server 這兩種資料庫差異蠻大的，先撇除開發時期 SQL 語法的差異，那完全是另外一個課題，本篇文章主要專注在如何將 MySQL 資料庫完整且正確的移轉到 SQL Server 裡。要移轉資料庫，透過 Microsoft SQL Server Migration Assistant v5.3 for MySQL 來移轉，應該是算是最方便的了，而且一次可以移轉多個資料庫，如果熟悉他的操作介面，就可以很有效率地完成移轉工作，完全不用寫轉檔程式。
我基本上將移轉任務區分為以下步驟：
- 下載並安裝相關工具與軟體 ( MySQL Connector/ODBC 5.1 與 SSMA v5.3 for MySQL )
- 準備來源資料庫 (MySQL)
- 修正 ZERO DATE 且 NOT NULL 的資料
- 準備目的資料庫 ( 建議使用 LocalDB 來進行資料轉檔任務 )
- 開啟 SSMA for MySQL 工具
- 建立新專案
- 連接 MySQL 資料庫
- 連接 SQL Server 資料庫
- 執行 Create Report
- 執行 Convert Schema
- 執行 Synchorize with Database
- 執行 Migrate Data
- 備份轉換成功的資料庫
- 移除資料庫中的擴充屬性
- 將資料庫移轉到 Azure SQL Database
步驟 1：下載並安裝相關工具與軟體
請先安裝好 MySQL Connector/ODBC 5.1 以上版本，以及 Microsoft SQL Server Migration Assistant v5.3 for MySQL 工具。
步驟 2：準備來源資料庫 (MySQL)
如果你的電腦可以連上 MySQL 就不用特別準備，否則你可能要先將資料庫匯出，並匯入到本機 MySQL 伺服器中，這樣可以加快移轉的速度。
步驟 3：修正 ZERO DATE 且 NOT NULL 的資料
由於 MySQL 早期都有許多所謂的 ZERO DATE 的日期格式，也就是 '0000-00-00' 這樣的日期，通常會用在當日期欄位不為空值，而又沒有日期資料的情況，就會塞入這種無效的日期格式。
由於 SQL Server 並不支援 ZERO DATE 這種格式，所以只要資料表中有這類的日期資料，那是一定無法移轉資料成功的，所以我會選擇在轉換資料前，先針對這些資料做一些修正，例如執行以下 SQL 命令：
UPDATE wp_posts SET post_date_gmt='1900-01-01 00:00:00' where post_date_gmt < '1900-01-01';
UPDATE wp_posts SET post_modified_gmt='1900-01-01 00:00:00' where post_modified_gmt < '1900-01-01';
步驟 4：準備目的資料庫
建議大家多多利用 LocalDB 來進行資料轉檔任務，因為 LocalDB 不但輕量，而且速度也不差，很適合用來做暫時性的資料庫操作。
有時你也可以先把資料庫給建立好，等等轉移的時候，就可以直接將 MySQL 資料庫直接應對到你預先建立的 SQL Server 資料庫之中。
步驟 5：開啟 Microsoft SQL Server Migration Assistant v5.3 for MySQL 工具
接著就準備進入 SSMA for MySQL 工具的使用教學，請先開啟 SSMA for MySQL 工具。
- 建立新專案
請選擇目的地的 SQL Server 資料庫版本：
- 連接 MySQL 資料庫
注意：Provider 請務必選擇 “Unicode” 版本的 Driver 喔！
SSMA for MySQL 工具預設幫你做好了所有欄位類型的對應表，但你可以修改這個對應，在這套工具裡，預設會把 MySQL 的 datetime 對應到 SQL Server 的 datetime2 型態，但我通常我不太愛用 datetime2 資料型態，所以我會修改 Type Mapping 將 MySQL 的 datetime 對應到 SQL Server 的 datetime 型態就好，這時你可以參考下圖設定：
- 連接 SQL Server 資料庫
這個步驟你可以隨便選一個資料庫來連線，但不一定要把 MySQL 資料庫匯入到這個 SQL Server 資料庫中，重要的是你連線的這個身分是否有足夠的權限可以建立新資料庫。如果你權限不夠，那可能就要先請 DBA 將資料庫先建立好，然後再建立資料庫連接。
如果你打算在本機直接完成所有移轉動作，那麼你可以忽略以下這個訊息：
- 執行 Create Report
這個步驟就要先選擇你有哪些 MySQL 資料庫要移轉過去，請先勾選起來。勾選完之後，你也可以修改 Schema Mapping 設定，其實就是哪個 MySQL 資料庫要對應到哪一個 SQL Server 資料庫的意思。
以下圖為例，Source Schema 的 wordpress 就是 MySQL 中的資料庫名稱 (Database Name)，而 Target Schema 的 wordpress.dbo 代表的則是 wordpress 資料庫下的 dbo 結構描述，也就代表 MySQL 中 wordpress 資料庫中所有表格，都會匯入成 SQL Server 中 wordpress 資料庫的 dbo 結構描述中。
接著你就可以建立報表
這裡的「報表」指的是【幫你檢查在轉換資料庫的過程中，預計會有多少表格可以成功被移轉】，而且還可以在這個介面看到 MySQL 與 SQL Server 之間在建立表格時的 SQL 語法比較。
- 執行 Convert Schema
確認轉換過程沒有大問題之後，就要開始轉換 Schema 了。
當你按下 Convert Schema 之後，並不會真的到你的 SQL Server 建立資料庫與資料表，而是先幫你產生 SQL Server Metadata 而已：
- 執行 Synchorize with Database
請在建立好 SQL Server Metadata 之後，直接在 SQL Server Metadata Explorer 窗格中的該資料庫上按下滑鼠右鍵，並選擇 Synchorize with Database 動作，這個動作就會真的連接到你的 SQL Server 並且將資料庫、結構描述物件與資料表物件都給建立起來。
當你在上圖按下 OK 之後，SQL Server 就會真的被建立起新的資料庫與資料表物件了，只是沒有資料而已：
- 執行 Migrate Data
最後你只要在要轉換的 MySQL 資料庫上按下滑鼠右鍵，並選擇 Migrate Data 即可開始移轉資料：
這時他還會要求你再次輸入密碼，不過重點還是在 Provider 喔！記得選 Unicode 這個 Driver！！
最後你會得到一個轉換結果報告，如果都是 100% 的話，那就恭喜你轉換成功啦！ ^_^
步驟 6：備份轉換成功的資料庫
通常我轉換完畢後，會先將資料庫備份起來。
步驟 7：移除資料庫中的擴充屬性
如果你要移轉資料庫到雲端的 SQL Database 裡面，建議還是檢查一下是否有不支援的擴充屬性，詳細操作步驟請參考我的另一篇文章：從本地 SQL 資料庫遷移到雲端 SQL Database 的注意事項
步驟 8：將資料庫移轉到 Azure SQL Database
最後一步，才是將資料庫完整遷移到雲端 SQL Database 資料庫裡。
切記：千萬不要直接從 SSMA for MySQL 工具將 MySQL 資料移轉到雲端 SQL Database，因為這樣移轉的效率是最差的！
相關連結