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

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

操作要点：

• 右键目标 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 字段超长被静默截断、以及迁移后应用连不上——这些都藏在字段映射和字符集细节里，没法靠自动工具兜底。