Navicat 17 不支持 SQLite 与 MySQL 的跨库结构/数据对比，因其同步功能依赖服务端数据库特性（如 INFORMATION_SCHEMA），而 SQLite 作为嵌入式数据库缺乏相应接口；替代方案为导出 SQL 或 CSV 后人工比对。
Navicat 17 不支持 SQLite 和 MySQL 的跨库结构/数据对比
直接结论：Navicat 17 的「结构同步」和「数据同步」功能**完全不支持 SQLite 作为源或目标端参与对比**。右键 SQLite 连接时，根本不会出现「结构同步」菜单项；即使强行在 MySQL 端发起同步，也无法选择 SQLite 为另一侧——这不是操作遗漏，而是底层驱动限制。
原因很实在：SQLite 是无服务端的嵌入式数据库，没有网络协议、事务日志或元数据查询接口（如 INFORMATION_SCHEMA），Navicat 同步模块依赖这些能力做差异计算，而 SQLite 驱动只提供基础的文件读写和简单 PRAGMA 查询，无法支撑双向比对逻辑。
常见误操作现象：
- 在 MySQL 连接上右键 →「结构同步」→ 尝试添加 SQLite 连接为“目标”，列表为空或报错
Unsupported source type - 用「数据传输」功能选 SQLite 为源、MySQL 为目标，但勾选了「同步结构」，结果建表失败或字段类型错乱（比如
INTEGER PRIMARY KEY被映射成INT NOT NULL，丢掉自增）
可行替代路径：导出 SQL + 手动比对结构
若只需核对表结构是否一致（字段名、类型、主键、NOT NULL），可走「导出 → 人工比对」流：
- 对 SQLite 表：右键 →「导出向导」→「导出为」选
SQL 文件→ 勾选「导出结构」→ 注意勾选「使用引号包围字段名」（防order等关键字冲突）→ 保存为sqlite_schema.sql - 对 MySQL 表：右键 →「备份数据库」→「结构」→ 生成
mysql_schema.sql；或用命令行mysqldump --no-data -u user -p db table > mysql_schema.sql - 用文本工具（如 VS Code、DiffMerge）打开两个 .sql 文件，搜索
CREATE TABLE块，逐字段比对：TEXTvsVARCHAR(255)、INTEGER PRIMARY KEYvsINT AUTO_INCREMENT、默认值是否丢失等
注意：Navicat 17 导出 SQLite 的 TEXT 默认映射为 VARCHAR(255)，但实际 SQLite 中无长度限制；若 MySQL 目标列真设成 VARCHAR(255)，后续插入超长内容会截断——比对时得手动确认是否应改为 MEDIUMTEXT。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
数据行级差异只能靠 CSV 中转 + 外部工具
想查哪些记录在 SQLite 里有、MySQL 里没有，或数值不一致？Navicat 17 没有内置 diff 工具，必须导出后用外部手段比对：
- SQLite 端：右键表 →「导出向导」→ 格式选
CSV→ 编码选UTF-8→ 勾选「首行为列名」→ 分隔符建议用\t（制表符），避开字段内逗号/换行导致解析错位 - MySQL 端：右键表 →「导入向导」→ 同样选
CSV→ 编码UTF-8→ 分隔符匹配 →「数据行从第 2 行开始」→ 导出为临时表（如tmp_sqlite_copy） - 执行 SQL 比对（在 MySQL 中）：
SELECT 'in_sqlite_only' as src, id, name FROM tmp_sqlite_copy<br>WHERE id NOT IN (SELECT id FROM real_table)<br>UNION ALL<br>SELECT 'in_mysql_only', id, name FROM real_table<br>WHERE id NOT IN (SELECT id FROM tmp_sqlite_copy);
布尔字段（如 status）要特别留心：SQLite 存 1/0，MySQL 目标列需是 TINYINT(1)；若导成 CSV 后显示为 TRUE/FALSE，导入前得用文本编辑器全局替换成 1/0，否则 MySQL 会转成 0（因非数字字符串转整型失败）。
真正被忽略的难点：时间字段与空值语义
SQLite 没有原生日期类型，通常用 TEXT（如 '2026-10-20 14:30:00'）、INTEGER（Unix 时间戳）或 REAL（Julian 日）存储；MySQL 对应的是 DATETIME 或 INT。Navicat 导出时不会自动转换格式，导出的 SQL 里仍是原始字符串，直接导入 MySQL 可能因格式不匹配被转成 0000-00-00 00:00:00。
另一个隐形坑是空字符串 '' 和 NULL 的混用：SQLite 允许 TEXT 列存空字符串，MySQL 若目标列为 NOT NULL 且无默认值，导入时就会报错 Column 'xxx' cannot be null——这问题不会在结构对比里暴露，只有跑数据时才崩。
