常见原因是目标数据库缺失或权限不足：1.未提前创建同名数据库（需与sql文件中use语句一致）；2.当前账户缺乏create table、insert等必要权限；3.大文件导入时事务超时；4.文件含drop/create database语句但环境禁止建库；5.编码不匹配或语法不兼容。
“运行 sql 文件”导入失败，常见原因是什么
直接右键数据库选“运行 sql 文件”却报错或没反应，大概率是目标库缺失对应数据库（schema）或权限不足。navicat 导出的 .sql 文件默认包含 create database 和 use database_name 语句，但如果你手动删掉了这些语句，或目标环境禁止建库，就会卡在第一步。
实操建议：
- 先确认目标服务器上是否存在同名数据库；不存在就手动创建，名称必须和
.sql文件里USE后面的名称完全一致（区分大小写） - 检查当前连接账户是否有
CREATE TABLE、INSERT权限；仅SELECT权限无法导入 - 若文件开头有
DROP DATABASE或CREATE DATABASE，而你不想重建库，可打开文件用文本编辑器删掉这几行再导入 - 导入大文件（>50MB）时，Navicat 默认会启用事务包裹全部语句，容易触发超时；可在导入前勾选“忽略错误继续执行”并关闭“使用事务”选项
用“数据传输”功能跨库迁移，比导出 SQL 更稳吗
是的，尤其当源库和目标库结构不完全一致、或需要字段映射/类型转换时，“数据传输”比纯 SQL 导入更可靠。它不依赖 SQL 解析，而是走 JDBC/ODBC 直连读写，绕过了语法兼容性问题（比如 Oracle 的 NUMBER(10,2) 自动转为 MySQL 的 DECIMAL(10,2)）。
实操建议：
- 菜单栏选
工具 → 数据传输，而非右键导出；源和目标需提前配置好两个独立连接 - 在“高级”选项里务必勾选“忽略外键约束检查”，否则目标表有外键时可能因插入顺序报错
- 若目标表已存在且含数据，选择“追加记录”模式；如要清空重导，选“删除现有记录后再插入”
- 对超大表（>100万行），开启“分批提交”，设每批 5000 行；同时关闭“验证数据完整性”，能提速 3 倍以上
从 Excel 或 CSV 导入到 MySQL，为什么字段全变成 NULL
这几乎总是编码或分隔符识别失败导致的。Navicat 默认按 UTF-8 解析文件，但 Excel 保存为 CSV 时实际可能是 GBK 或 UTF-8 with BOM，而 Navicat 无法自动检测 BOM 头。
实操建议：
- 用记事本另存为 CSV 时，明确选“UTF-8”（不要选“UTF-8-BOM”）；或用 VS Code 打开后底部状态栏切换编码再保存
- 导入向导第 3 步中，“字段分隔符”别依赖自动识别——Excel 导出的 CSV 多用英文逗号，但中文 Excel 可能用顿号或制表符，手动选准
- 如果第一行是列名，确保勾选“第一行包含列名”；否则 Navicat 会把标题当数据，导致后续所有行偏移
- 日期字段（如
2026-07-27）导入失败？在字段映射页手动将目标列类型设为DATE，并点击“格式”填入yyyy-MM-dd
Oracle 到 MySQL 迁移，哪些类型映射最容易出错
Navicat 能自动处理大部分类型，但 VARCHAR2、NUMBER 和 DATE 这三类在细节上常翻车：Oracle 的 VARCHAR2(100 CHAR) 对应 MySQL 的 VARCHAR(100) 没问题，但若源字段含 emoji 或中文，MySQL 必须用 utf8mb4 排序规则，否则截断；NUMBER 无精度定义时会被转成 DOUBLE，丢失整数语义。
实操建议：
- 在“数据传输”字段映射页，逐个点开目标列的“类型”下拉框，把
NUMBER显式改为BIGINT或DECIMAL(19,4)，避免默认DOUBLE - 目标 MySQL 库/表字符集必须设为
utf8mb4，排序规则选utf8mb4_unicode_ci；仅改连接字符集无效 - Oracle 的
DATE包含时分秒，MySQL 的DATE只存日期——如需完整时间，目标列类型必须设为DATETIME或TIMESTAMP - 迁移前用 Navicat 执行
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'查源库字符集，比盲目猜更靠谱
跨库导入真正麻烦的从来不是按钮在哪，而是隐式假设：比如认为“同名数据库一定存在”“CSV 就该是 UTF-8”“NUMBER 就等于 INT”。每个跳过的确认步骤，都可能让导入结果差一条记录、一个字段、一种精度。
