可行但默认配置必失败，需手动干预主键约束、字符集（utf8mb4）、类型映射（integer→signed、real→decimal）及清理临时表。
直接用 navicat 16 的「数据传输」功能迁移 sqlite 到 mysql 是可行的，但默认配置大概率失败——主键空值、类型映射错位、中文乱码、临时表残留这四类问题几乎必现，必须手动干预。
为什么数据传输向导一运行就报错“主键列不能为 NULL”
SQLite 允许 INTEGER PRIMARY KEY 列插入 NULL（自动触发 rowid 分配），而 MySQL 的 AUTO_INCREMENT 主键严格拒绝 NULL。Navicat 在传输时不会自动补全缺失主键值，而是原样尝试插入，导致中断。
解决方法：
- 在「数据传输」第三步「选择要传输的数据库对象」后，点击「选项」按钮 → 勾选
忽略主键约束和忽略外键约束 - 若目标 MySQL 表已存在且含数据，先手动执行
TRUNCATE TABLE清空，避免主键冲突 - 迁移完成后，立即在 MySQL 中执行
ALTER TABLE `table_name` MODIFY COLUMN `id` INT AUTO_INCREMENT;激活自增
text / varchar 字段导入后中文变问号或乱码
根本原因不是 Navicat 没选 UTF8，而是它只设置了数据库和连接层字符集，没管字段级定义。SQLite 文件本身是 UTF-8 编码，但 Navicat 默认把 TEXT 映射为 TEXT 类型且不带 CHARACTER SET utf8mb4，MySQL 用默认的 latin1 解析，中文直接崩。
操作要点：
- 迁移前，在 MySQL 目标库执行：
ALTER DATABASE `your_db` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 在「数据传输」→「选项」→「高级」中，强制指定：
字符集设为utf8mb4，排序规则设为utf8mb4_unicode_ci - 迁移完成后，对每个 text/varchar 字段单独执行：
ALTER TABLE `t` MODIFY COLUMN `c` TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
迁移后发现数值异常：负数变极大正数、小数点消失
这是类型映射硬伤。Navicat 把 SQLite 的 INTEGER 统一映射成 MySQL 的 BIGINT UNSIGNED，导致负数溢出；把 REAL 映射成 DOUBLE 却丢掉了精度声明，部分浮点数被截断。
必须提前干预类型映射：
- 不要依赖「全部表自动映射」，在「选择对象」步骤后，点击「编辑映射」→ 手动将
INTEGER改为BIGINT SIGNED或INT SIGNED（根据实际范围） - 将
REAL显式改为DECIMAL(12,4)等带精度的类型，避免浮点误差 - 若 SQLite 有
NUMERIC(10,2)这类声明，Navicat 会误判为DECIMAL(10,0)，务必手动修正小数位
迁移中途失败，重试仍卡在同一个表
SQLite 在写入失败时会生成形如 sqlite_autoindex_table_1 或 table_name_new 的临时表，Navicat 下次扫描时会再次尝试迁移它们，形成死循环。
快速清理办法：
- 用 DB Browser for SQLite 打开原
.db文件 → 切换到「Browse Data」→ 点击左上角「Table」下拉框 → 删除所有名称含autoindex、_new、_bak的表 - 或者在 Navicat 中右键 SQLite 连接 → 「打开终端」→ 执行：
SELECT name FROM sqlite_master WHERE type='table' AND name LIKE '%temp%';，再逐个DROP TABLE - 删完立刻重启 Navicat，再走一遍数据传输流程
真正耗时的从来不是点击几下「下一步」，而是校验每张表的字段类型是否被悄悄改写、每条中文是否还保持原样、每个负数有没有变成 18446744073709551615——这些细节不会报错，但会让生产环境的数据逻辑彻底失效。
