DBeaver执行导出的SQL文件需右键目标数据库→“Execute SQL Script”，选中文件并勾选“Continue on error”；大文件应关闭Auto-commit、手动加事务控制；注意检查数据库存在性、默认库设置、字符集匹配及外键约束语句。
怎么在DBeaver里执行之前导出的SQL文件
直接执行就行，DBeaver本身不提供“导入数据库”的独立功能，而是靠执行SQL脚本来还原数据。关键不是找“导入按钮”，而是用正确的执行方式——否则容易卡住、报错或只执行了前几行。
- 右键目标数据库 → Execute SQL Script（不是“Open SQL Editor”）
- 选中你的
.sql文件，勾选Continue on error（尤其含DROP TABLE或重复建表时必开） - 确认连接用户有足够权限（比如
CREATE、INSERT、DROP） - 大文件（>10MB）建议先关掉
Auto-commit，并在脚本开头手动加BEGIN TRANSACTION;，末尾加COMMIT;
执行时报错 “No database selected” 或 “Unknown database” 怎么办
这是最常卡住的地方：DBeaver不会自动把SQL文件绑定到当前选中的数据库，尤其是导出时用了 USE db_name; 但目标库不存在，或脚本里写的是绝对库名而当前连接没切换过去。
- 检查SQL文件开头是否有
USE `xxx`;—— 如果目标库不存在，得先手动创建：CREATE DATABASE IF NOT EXISTS `xxx`; - 执行前，在左侧数据库导航树中，**右键目标数据库 → Set as Default**（否则即使连着该库，脚本也可能跑在 default schema 空间）
- 如果脚本里全是带库前缀的表名（如
mydb.users），确保mydb已存在且用户有访问权限 - MySQL下遇到
Unknown database却确认库存在？可能是库名含短横线（-）但没用反引号包裹，脚本里应为`my-db`而非my-db
为什么只导入了部分表，或者 INSERT 全失败
常见于导出时用了兼容模式或字符集不一致，导致执行时解析中断或字段值被截断。DBeaver默认用UTF-8读取文件，但如果SQL文件是GBK/GB2312保存的，中文INSERT会直接报语法错误。
- 打开SQL文件 → 右上角点击编码标识（如
UTF-8）→ 选对应原始编码（常用GBK或ISO-8859-1）再重试 - 检查脚本里是否有
SET NAMES或CHARACTER SET语句——如果和目标库实际字符集冲突（比如脚本设utf8mb4，但库是latin1），删掉或改成匹配值 - INSERT 失败常因外键约束：导出时没勾选
Disable foreign key checks，还原时又没在脚本开头加SET FOREIGN_KEY_CHECKS = 0;和结尾加SET FOREIGN_KEY_CHECKS = 1; - PostgreSQL 用户注意：
psql导出的.sql含 \set、\connect 等元命令，DBeaver不识别，必须用psql -f xxx.sql命令行导入
有没有比 Execute SQL Script 更稳的还原方式
有，但要看数据库类型。对MySQL/MariaDB，用原生命令行工具更可靠，尤其处理大文件或特殊语法；DBeaver只是图形界面，底层仍调用JDBC执行，对事务控制、错误恢复能力有限。
- MySQL：终端执行
mysql -u user -p database_name （推荐，跳过DBeaver编码/缓冲限制） - PostgreSQL：用
psql -U user -d dbname -f dump.sql（DBeaver不支持COPY二进制格式还原） - 如果必须用DBeaver，大文件建议拆分：用文本编辑器按
CREATE TABLE或INSERT INTO分段保存，逐个执行 - 别依赖DBeaver的“SQL Execution Plan”或“Result Set”来判断是否成功——看底部状态栏的
Executed N statements和红色错误提示才准
真正容易被忽略的是SQL文件的“上下文一致性”：导出时的SQL模式（sql_mode）、时区（time_zone）、autocommit设置，都会影响还原行为。光把文件丢进去执行，不核对这些，等于在猜结果。
