Navicat「数据传输」比「导入向导+ODBC」更稳，因其不依赖本地驱动、规避Windows身份验证失败，支持手动精准映射datetime2、uniqueidentifier等字段类型，并可同步表结构、校验主键索引与数据完整性。
直接用 Navicat 的「数据传输」功能，别碰「导入向导 + ODBC」——后者在 Windows 上大概率卡死在身份验证或驱动缺失上，且 datetime2、uniqueidentifier 等字段映射不可控。
为什么「数据传输」比「导入向导」稳得多
「导入向导」依赖本地安装 SQL Server OLE DB Provider 或 ODBC Driver，而 Windows 系统常缺驱动、防火墙拦截、实例名写错（比如漏掉 \SQLEXPRESS），甚至勾选了「允许保存密码」却没打钩导致登录失败。即使连上了，datetime2(7) 会被草率转成 DATETIME 丢精度，uniqueidentifier 可能变成乱码，GETDATE() 默认值直接消失。而「数据传输」走的是 Navicat 内置连接协议，不依赖本地驱动，也不走 Windows 身份验证，全程用 SQL 登录账号，连接更干净。
迁移前必须手动做好的三件事
目标 MySQL 数据库得提前建好，字符集必须设为 utf8mb4，排序规则建议 utf8mb4_unicode_ci；源 SQL Server 和目标 MySQL 连接都得在 Navicat 里测试通，账号权限要确认清楚：SELECT + LOCK TABLES 对源库，CREATE + INSERT + INDEX + ALTER 对目标库；所有表名、字段名、约束名不能含中文或特殊符号——Navicat 在跨库映射时对非 ASCII 名称兼容性差，容易报 Invalid object name 或跳过对象。
字段类型和默认值怎么手动映射才不出错
进「数据传输」→「表映射」页→每张表点「编辑」，重点改这几项：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
datetime2(n)→ 改成DATETIME(n)（例如datetime2(7)→DATETIME(3)，MySQL 8.0 支持最多 6 位微秒，但业务通常 3 位够用） -
uniqueidentifier→ 改成CHAR(36)，别用UUID类型（MySQL 原生UUID是函数，不是数据类型） -
bit→ 改成TINYINT(1)，否则 Navicat 可能映射成BOOLEAN导致插入失败 -
IDENTITY列 → 目标自动设为AUTO_INCREMENT，但主键约束不会自动加，得手动补PRIMARY KEY -
DEFAULT GETDATE()或其他函数默认值 → 「默认值」列必须留空，MySQL 不支持函数默认值，后续得靠应用层或触发器补
空字符串 '' 在 SQL Server 合法，但在 MySQL 严格模式下会报 Data truncated for column，要么提前在源库清理，要么临时关掉目标库的 STRICT_TRANS_TABLES 模式。
迁移完必须立刻核对的三项事实
行数一致 ≠ 数据一致。必须立刻执行：
- 对比表结构：
SHOW CREATE TABLE 表名，确认主键、索引、NOT NULL、DEFAULT是否完整；SQL Server 的非聚集索引 Navicat 不同步，得手动重建 - 查字段可空性：
SELECT column_name, is_nullable, column_default FROM information_schema.COLUMNS WHERE table_name = 'xxx'，特别注意源库NOT NULL字段带默认值的，在 MySQL 里可能变成NULL或空字符串 - 校验数据完整性：SQL Server 执行
CHECKSUM_AGG(BINARY_CHECKSUM(*))，MySQL 执行MD5(GROUP_CONCAT(CONCAT_WS('|', col1, col2, ...)))，两者比对——只看行数或抽样几条根本不可靠
真正麻烦的从来不是点「开始」，而是 datetime2 里那毫秒级的偏差、uniqueidentifier 中大小写的混用、以及你忘了关 MySQL 严格模式——这些细节不盯死，上线后查半天才发现订单时间全错了。
