报错本质是目标数据库禁用或不支持声明的存储引擎。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 是否被保留、是否符合目标库实际能力
