最近在《進行資訊系統轉換》時，有些後端資料庫也必須從微軟的 MS Access (.accdb) 升級到 MySQL 8，以方便統一維護，也怕微軟公司哪天像《MS Publisher 那樣不再支援了》。然而，將帶有 Windows 歷史包袱的 Access 轉移到 MySQL，尤其在繁體中文的環境下，可不是一件點點滑鼠就能完成的輕鬆事。這篇文章記錄了這次移轉過程中評估的「三種兵器」，以及最終的最佳解法，希望能幫會經歷同樣痛苦的工程師少走一點冤枉路。
MySQL Workbench 遷移精靈 (看似美好，實則踩雷)
身為 MySQL 的官方工具，Workbench 內建的 Migration Wizard 通常是大家的第一選擇。它提供了視覺化的精靈介面，標榜能全自動讀取 .accdb 的結構並轉換。
- 使用方式：透過建立系統的 ODBC DSN（需安裝 64 位元的 Access Database Engine），讓 Workbench 連線讀取來源，再一路 Next 到底進行轉換。
- 優點：介面直覺，對於純英文、無特殊資料型態的微型資料庫，確實能一鍵完成。
- 在中文環境下的致命缺點 (根本是廢物)：
- 資料型態誤判：會把 Access 的日期時間類型誤判為 MySQL 拒絕接受的 DATETIME(19)，導致建立資料表時直接報錯 (Error 1426)。
- 編碼崩潰地雷：這是最讓人挫折的一點。其底層的搬運程式 wbcopytables.exe 存在嚴重的多國語系缺陷。當它讀取到中文資料表或欄位名稱時，Python 監控腳本會因為無法解析 cp950（Windows 繁體中文編碼）而發生資料建立錯誤。無論你怎麼在介面上強制指定 UTF-8 或 Big5 都無濟於事，除非你把 Access 裡的所有欄位名稱都暫時改成英文。
- ODBC 驅動程式不相容：測試到最後匯入編碼改為與 MySQL 相同的 utf8mb4，終於匯入所有資料表，但中文部分欄位全部是亂碼，因為它還是以編碼 cp950 匯入資料。
Access 內建 ODBC 匯出 (土法煉鋼，但堪用慎用)
既然微軟與 Oracle 的工具水土不服，第二種方法是回到 Access 本身，利用它內建的匯出功能，搭配 MySQL 8.0 Unicode Driver 直接把資料「推」進 MySQL Server。
- 使用方式：在 Windows 設定好指向 MySQL 8 的 ODBC 連線。接著在 Access 中選取資料表，按右鍵選擇「匯出」->「ODBC 資料庫」，逐一將資料表倒進 MySQL。
- 優點：不需要透過第三方工具的轉換層，直接依賴 Windows 底層的 ODBC 驅動程式，避開了 Workbench 的腳本閃退 Bug。
- 缺點與隱藏陷阱：
- 純手工作業：效率極低。如果你的系統有幾十張資料表，光是逐一點擊所有資料庫，就會滑鼠點到手軟。
- 索引與主鍵流失：無法完美保留索引 (Indexes) 與主鍵的自動遞增 (Auto-Increment) 屬性，匯出後還得自己在 MySQL 裡手動補齊結構。
- 「位元組」型態的溢位陷阱：如果你的 Access 資料表中有設定為「數字 / 位元組 (Byte)」的欄位（範圍是 0~255），透過 ODBC 直接匯出建立 MySQL 資料表時，通常會被自動映射成 MySQL 的 TINYINT。致命的是，MySQL 的 TINYINT 預設是正數 (Signed)，範圍只有 -128 到 127。只要你的 Access 資料裡有大於 127 的數值，匯入時就會無情地噴出 “Out of range value for column xx” 的錯誤，導致該筆資料寫入失敗。要解決這個問題，只能先在 MySQL 端手動建好結構，並明確宣告為 TINYINT UNSIGNED 或 SMALLINT（先改為整數類型）。
推薦 DBeaver 社群版工具（最佳解法）
經過反覆測試，真正能優雅解決編碼與轉換問題的，是開源的資料庫管理工具 DBeaver 。它支援各種資料庫之間的移轉，號稱「Universal Database Manager」。DBeaver 這個名字是由 Database 和 Beaver（海狸）結合而來的（封面圖上那隻）。
- 使用方式：在 DBeaver 中分別建立 Access 與 MySQL 的連線。全選 Access 的資料表後，按右鍵選擇「匯出數據 (Export Data)」，目標指向 MySQL。
- 優點：
- 無痛處理中文編碼：DBeaver 底層讀取 Access 時，使用的是 Java 體系的 UCanAccess 驅動程式（這在過去 Tomcat 後台環境曾使用）。它直接讀取檔案位元組並轉為純淨的 UTF-16 Unicode，完全繞過了 Windows ODBC 那層充滿歷史包袱的 CP950 編碼地雷。
- 視覺化的欄位映射修正 (完美解決 DATETIME 錯誤)：這是 DBeaver 勝出 Workbench 的關鍵細節。前面提到 Workbench 會死板地將 Access 日期轉為 MySQL 拒收的 DATETIME(19) 導致建表失敗；而在 DBeaver 中，正式匯出前會提供一個直覺的「Mapping (映射)」畫面。開發者可以清楚審視每一個欄位的對應關係，若發現預測的型態有誤，只需直接在目標型態 (Target Type) 欄位手動修改，例如把多餘的括號刪除，修正為標準的 DATETIME 或獨立的 DATE、TIME，就能精準拆彈，順利匯出 Access 資料庫。
- 批次處理：可以一次選取所有資料表進行背景搬運，大幅節省時間。
- 備註：對於極端不合理的資料定義仍需要手動微調。例如 Access 若定義了 Numeric(100,2)，在 MySQL 8 會因為超過最大精度 (65 位) 而報錯，需在剛剛提到的映射畫面中，手動改為合適的精確度。
- 關於 UCanAccess：它是 Pure Java (Type 4 JDBC) 驅動程式。這意味著它不需要依賴 Windows 系統層級的 ODBC 驅動程式（透過 Jackcess & HSQLDB 引擎直接讀取檔案位元組），這也是為什麼它在 DBeaver 裡能輕鬆解決編碼與系統資料表權限問題的原因。安裝此工具時，預設是會順便安裝 Java 軟體。