Navicat「数据传输」比「导入向导+ODBC」更稳，因其无需依赖本地驱动、规避Windows身份验证失败，且支持手动精准映射datetime2、uniqueidentifier等字段类型，并可同步表结构、校验主键索引与数据完整性。
直接用 navicat 的「数据传输」功能最稳，比「导入向导 + odbc」成功率高、字段映射更可控，且能跳过 windows 身份验证失败、驱动缺失等常见卡点。
为什么不用「导入向导」选 ODBC
这个路径依赖本地安装 SQL Server OLE DB Provider 或 ODBC Driver，Windows 系统常缺驱动、防火墙拦截、SQL Server 实例名写错（比如漏掉 \SQLEXPRESS）、或勾选了「允许保存密码」却没打钩导致登录失败。即使连接成功，datetime2、uniqueidentifier、带默认值的列也容易转换异常，工具自动映射的 DATETIME 类型可能丢精度，GETDATE() 默认值直接被忽略。
无序列表呈现关键问题：
- ODBC 配置需手动装驱动，Navicat 不自带
- Windows 身份验证在远程连接时大概率失败，必须切 SQL 账号并开启混合模式
- 表结构迁移中，
IDENTITY列转成AUTO_INCREMENT但不自动设主键，需手动补 - 空字符串
''在 SQL Server 中合法，在 MySQL 严格模式下会报错，得提前清理或关 strict mode
用「数据传输」替代导入向导
前提是：你已用 Navicat 分别连上 SQL Server 源库和 MySQL 目标库（目标库需提前建好，字符集建议设为 utf8mb4）。
操作要点：
- 右键目标 MySQL 数据库 → 选「数据传输」
- 「源」选已连好的 SQL Server 连接；「目标」选当前数据库
- 点击「高级」→ 勾选「同步表结构」，否则只传数据不建表
- 在「表映射」页，对每张表点「编辑」→ 手动检查字段类型：把
datetime2(7)改成DATETIME(3)，uniqueidentifier改成CHAR(36)，bit改成TINYINT(1) - 「默认值」列留空——MySQL 不支持函数默认值（如
GETDATE()），得后续用触发器或应用层补
迁移后必做的三件事
数据进去了不等于能用。以下动作漏一项，上线就出问题：
- 执行
SHOW CREATE TABLE对比源表和目标表：确认主键、索引是否完整；Navicat 同步结构时会丢掉 SQL Server 的非聚集索引，得手动重建 - 查
information_schema.COLUMNS，核对is_nullable和column_default是否一致；尤其注意NOT NULL字段在 SQL Server 有默认值，迁到 MySQL 后变成NULL或空值 - 跑一次
CHECKSUM_AGG(BINARY_CHECKSUM(*))（SQL Server）和对应MD5(GROUP_CONCAT(...))（MySQL）比对全表校验和——仅靠行数一致不能证明数据没变形
真正麻烦的从来不是点几下「开始」，而是 datetime 精度截断、GUID 大小写混存、text 字段超长被静默截断、以及迁移后应用连不上——这些都藏在字段映射和字符集细节里，没法靠自动工具兜底。
