Navicat Premium 15解决导入数据时存储引擎不支持报错的方法

报错本质是目标数据库禁用或不支持声明的存储引擎。MySQL需检查SHOW ENGINES；PostgreSQL不支持ENGINE等子句；SQLite需确认扩展模块是否启用；跨库迁移须校验引擎语义一致性。

MySQL 5.7+ 导入报错 “Unknown storage engine ‘InnoDB’” 或 “Storage engine not supported”

这类报错本质不是 navicat 的问题，而是目标 mysql 实例禁用了 innodb（或其它声明的引擎），常见于精简版、docker 镜像、或手动编译时关闭了引擎支持。navicat 在解析 create table 语句时发现 engine=innodb 却无法加载该引擎，就会中止导入。

验证方式：连上目标库执行 SHOW ENGINES;，检查 InnoDB 行的 SUPPORT 列是否为 NO 或 DISABLED。

• 若为 NO：说明编译时未启用，需重装支持 InnoDB 的 MySQL 二进制包
• 若为 DISABLED：检查配置文件中是否含 skip-innodb 或 disabled_storage_engines = "innodb"，删掉并重启 mysqld
• 临时绕过（仅调试）：用文本编辑器打开 SQL 文件，全局替换 ENGINE=InnoDB → ENGINE=MyISAM（注意 MyISAM 不支持事务和外键）

PostgreSQL 导入时提示 “unknown storage parameter” 或忽略 USING INDEX 报错

Navicat 从其他数据库（如 MySQL）迁移或导出的 SQL，常带 MySQL 风格的存储参数，例如 USING INDEX TABLESPACE pg_default 或 ROW_FORMAT=DYNAMIC。PostgreSQL 不识别这些，会直接报语法错误。

关键点：PostgreSQL 没有 “存储引擎” 概念，只有访问方法（ACCESS METHOD）和表空间，且不接受 MySQL 的 ENGINE/ROW_FORMAT 等子句。

• 必须删除所有 ENGINE=...、ROW_FORMAT=...、KEY_BLOCK_SIZE=...、STATS_... 类参数
• USING INDEX 在 PostgreSQL 中仅用于 CREATE INDEX，不能出现在 CREATE TABLE 里——删掉整段
• 若 SQL 来自 Navicat 自动导出，建议改用“结构同步”而非“SQL 文件导入”，避免生成跨引擎语句

SQLite 导入失败，报错 “no such module: fts5” 或 “unknown storage class”

SQLite 本身没有传统意义的存储引擎，但扩展模块（如 fts5、json1、rtree）被误当作引擎引用时，Navicat 会尝试执行含 USING fts5 的建表语句，而目标 SQLite 库未启用对应模块。

典型场景：从支持 FTS5 的 SQLite 导出，再导入到旧版或裁剪版 SQLite（如某些嵌入式环境）。

• 运行 PRAGMA compile_options; 查看是否含 ENABLE_FTS5
• 若缺失，可临时降级为 USING fts4（兼容性更好），或直接删掉 USING ... 子句改用普通列 + 全文检索逻辑
• Navicat 不会自动检测或提示模块缺失，错误只在执行时抛出 —— 必须提前确认目标 SQLite 构建选项

跨数据库迁移时 ENGINE 声明引发的隐性兼容问题

即使没报错，硬编码 ENGINE 也可能导致行为偏差。例如 MySQL 中 ENGINE=InnoDB 默认开启外键检查，而 ENGINE=MyISAM 完全忽略 FOREIGN KEY 定义 —— Navicat 不会警告，但数据一致性已丢失。

更隐蔽的是 MariaDB 的 Aria 引擎与 MySQL 的 InnoDB 在崩溃恢复、锁粒度上的差异，可能让迁移后查询变慢或死锁。

• 生产环境迁移前，务必在目标库执行 SELECT @@default_storage_engine; 确认默认值
• 不要依赖 Navicat 的“自动转换”：它只处理基础类型映射，不校验引擎语义等价性
• 对关键业务表，手动检查建表语句中 ENGINE 是否被保留、是否符合目标库实际能力

真正麻烦的不是报错本身，而是报错消失后留下的“安静缺陷”——比如引擎被静默降级、外键失效、全文索引不可用。这些不会中断导入，却会在上线后某个查询里突然暴露。