MySQL Workbench Migration Wizard可完成80%以上基础迁移，但需手动修正datetime→DATETIME、bit→TINYINT(1)、NVARCHAR→VARCHAR+utf8mb4等类型映射，并处理GETDATE()→NOW()、ISNULL→IFNULL等语法转换，否则数据丢失或报错。
直接用 MySQL Workbench 的 Migration Wizard 能完成 80% 以上的基础迁移，但必须手动干预数据类型映射和 T-SQL 特有语法，否则导入后表能建、数据会丢或报错。
Migration Wizard 连接 SQL Server 失败的常见原因
多数卡在第一步不是因为密码错，而是 ODBC 驱动没装对或权限配置不匹配：
- Windows 上必须安装
Microsoft ODBC Driver for SQL Server（非旧版 SQL Native Client），且版本要 ≥ 17；32 位 Workbench 必须配 32 位驱动，64 位同理 - SQL Server 实例若启用了 TCP/IP 但禁用了命名管道，
ODBC (Native)模式会连不上——此时改选ODBC (File DSN)并手动指定服务器名 + 端口（如192.168.1.100,1433）更稳 - Windows 认证模式下，Workbench 实际走的是当前登录用户的 NTLM 凭据，远程连接时需确认 SQL Server 已启用“混合模式”，且目标账户明确授予了
db_owner权限
datetime / bit / nvarchar 类型不转换就迁移必出错
Workbench 默认映射很粗糙：datetime 直接转成 timestamp，但 MySQL 的 timestamp 有年份范围限制（1970–2038）且自动时区转换，而 SQL Server 的 datetime 是无时区纯数值；bit 不转 TINYINT(1) 会导致 INSERT 失败；NVARCHAR 缺少字符集声明则中文变问号。
必须在 Migration Wizard 的 “Source Catalog Objects” 步骤后，进入 “Edit Column Mapping” 手动修正：
-
datetime→ 改为DATETIME（不是TIMESTAMP） -
bit→ 改为TINYINT(1)，并在目标建表语句中加COMMENT 'boolean'便于后续识别 -
NVARCHAR(n)→ 改为VARCHAR(n)，并确保建表语句末尾含CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci -
UNIQUEIDENTIFIER→ 改为CHAR(36)或BINARY(16)，后者节省空间但需应用层处理 UUID 二进制序列化
迁移后数据不一致，优先查这三处
即使 Migration Wizard 显示“100% 完成”，也常因隐式行为导致数据偏差：
-
GETDATE()在源表中是默认值，迁移到 MySQL 后变成静态时间戳（即迁移时刻），而非插入时动态生成 —— 需手动把目标列默认值改成NOW() - SQL Server 的
ISNULL(col, 'N/A')在迁移后仍保留原函数，但 MySQL 不认ISNULL()作空值替换（它只判断是否为 NULL），必须批量替换成IFNULL(col, 'N/A') - 源库若有
TEXT列且内容超 65535 字节，Workbench 可能截断不报错 —— 迁移后用SELECT id, LENGTH(col) FROM table_name WHERE LENGTH(col) > 65535快速筛查
真正耗时的从来不是工具点击，而是确认每张表里有没有隐藏的 COMPUTE 列、ROWGUIDCOL 标识、或依赖 @@ROWCOUNT 的触发器逻辑 —— 这些 Workbench 压根不处理，得靠人工逐个核对源库脚本。别跳过预检步骤，哪怕多花两小时看一遍 sp_help 'table_name' 输出。
