DBeaver无法直接导入dump文件，需根据场景选择“Execute Script”（JDBC执行，要求库已存在、权限充足）或“Restore Database”（调用本地mysql命令，支持建库和字符集设置），并务必检查编码（如去除UTF-8 BOM）、目标库存在性及用户权限。
DBeaver 不能直接“导入 dump 文件”——它实际是执行 SQL 脚本，而 mysqldump 生成的文件必须满足 MySQL 服务端能解析的语法和编码要求，否则会报错或静默失败。
为什么右键选 “Execute Script” 却报 unkown command '\"' 或乱码？
这是最常见也最容易被忽略的问题：DBeaver 默认用系统 locale 编码（比如 macOS 的 UTF-8、Windows 的 GBK）读取文件，但脚本里含中文或特殊字符时，若文件保存为 UTF-8 BOM 或导出时未指定 --default-character-set=utf8，MySQL 客户端就会把开头的 BOM 字节当命令解析，报类似 unkown command '"' 的错误。
- 确认 dump 文件真实编码：用
file -i your_dump.sql（macOS/Linux）或 VS Code 底部状态栏查看 - 如果显示
charset=utf-8但带 BOM，用iconv -f UTF-8 -t UTF-8-MAC your_dump.sql > clean.sql去除 BOM（macOS） - DBeaver 执行脚本前，务必在弹窗右下角点击“Encoding”下拉框，手动选
UTF-8，不要依赖自动检测
“Tools → Execute Script” 和 “Tools → Restore Database” 有什么区别？
二者底层调用完全不同，适用场景也截然不同：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
Execute Script：纯 SQL 执行，走 JDBC 连接，受限于当前连接的 MySQL 用户权限（比如不能CREATE DATABASE，除非显式USE db_name）、字符集设置、SQL 模式（如STRICT_TRANS_TABLES），适合已存在目标库、只导入表结构+数据的场景 -
Restore Database：调用本地mysql命令行客户端（不是 JDBC），需要你提前配好Client Home指向 MySQL 8+ 的安装目录（如/usr/local/mysql/bin），支持--default-character-set=utf8mb4等参数，能建库、设字符集、处理大事务，更接近原生mysql - 如果你的 dump 文件开头有
CREATE DATABASE ... CHARSET=utf8mb4;，必须用Restore Database，否则Execute Script会因权限或语法报错
导入前必须检查的三件事
跳过这三项，90% 的导入失败都源于此：
- 目标数据库是否存在？
Restore Database可自动创建，Execute Script不会——必须先手动CREATE DATABASE并USE它，或在脚本开头加USE your_db; - 当前连接用户是否有
INSERT、CREATE、ALTER权限？特别是导入含存储过程的 dump 时，还需CREATE ROUTINE权限 - dump 文件是否含不兼容语法？例如 MySQL 8.0+ 导出的
caching_sha2_password认证相关语句，在旧版 MySQL 或 JDBC 驱动中会触发Authentication plugin 'caching_sha2_password' cannot be loaded错误；此时要么升级目标库，要么用mysqldump --skip-column-statistics重导（MySQL 8.0.12+ 默认开启该选项）
真正卡住人的，往往不是“怎么点菜单”，而是 dump 文件的编码、权限边界、客户端版本这三者之间的隐式耦合。配好 Client Home、看清 dump 头部的 SET NAMES 和 CREATE DATABASE 语句、手动指定编码——比反复重试“Execute Script”省两个小时。
