DBeaver右键“复制表”是结构+数据的原子操作，需目标库已连接、有写权限且无同名表，否则报错中断；不经过剪贴板或中间文件。
右键“复制表”不是复制数据，是结构+数据的原子操作
很多人点完右键“复制表”就以为数据会自动飞过去，结果目标库空空如也——其实 DBeaver 的 复制表 功能默认是「结构 + 数据」一次性写入，但前提是目标数据库连接必须已建立且有写权限，且目标 schema 中不能存在同名表（否则报错中断）。它不走中间 SQL 文件，也不依赖剪贴板。
常见错误现象：点击“复制表”后弹出对话框没反应、进度条卡住、日志里出现 Table 'xxx' already exists 或 Permission denied。
- 执行前务必确认目标数据库连接处于“已连接”状态（小绿点亮起），而非仅配置好未连
- 如果目标表已存在，DBeaver 默认不覆盖，需手动勾选“替换现有表”或先删表
- PostgreSQL 用户注意：目标 schema 必须显式指定（如
public.my_table），否则可能写入default_schema导致查不到 - MySQL 用户若用低版本驱动（如 5.1.x），可能因
INSERT ... SELECT权限缺失失败，建议升级驱动或改用导出/导入模式
导出再导入：适合跨服务器、大表、需过滤或转换的场景
当源和目标数据库不在同一实例，或你想加 WHERE 条件、改字段类型、跳过某些列时，导出数据 → 导入数据 比“复制表”更可控。它生成的是可审计、可编辑的中间文件（SQL / CSV / XLSX）。
关键差异在导出类型选择：
-
Export Data对话框中，“Format”选SQL：生成CREATE TABLE+INSERT语句，适合结构一致且要重建表的场景 - 选
CSV或XLSX：只导出数据，需提前在目标库建好表；优势是支持流式导出（勾选Use streaming export），百万行也不卡内存 - 导出前点齿轮图标 → 勾选
Quote all values：防止含逗号、换行的字段被 CSV 解析错行 - 导出 CSV 时，“Encoding”务必设为
UTF-8，否则中文变乱码（尤其 Windows 系统默认 ANSI）
Ctrl+C 复制结果集 ≠ 复制整表，慎用于生产数据搬运
直接运行 SELECT * FROM table 后 Ctrl+C，本质是把当前结果集“快照”进剪贴板，不是读取全表。它受两个硬限制：一是 DBeaver 默认只加载前 200 行（可改，但不推荐），二是剪贴板容量有限，超 5 万行极易崩溃或丢数据。
这种操作只适合临时调试、小样本比对，绝不能当成“复制整表”的手段。
- 想看全表？先在结果网格右上角点齿轮 → 修改
Maximum number of rows to fetch（比如设为0表示不限），再重跑查询 - 但即使设了 0，Ctrl+C 仍可能因 JVM 堆内存不足失败——这是 GUI 工具的固有瓶颈，不是你配置错了
- 粘贴到 Excel 后发现时间字段少 8 小时？那是时区转换问题，DBeaver 默认按本地时区解析
TIMESTAMP，导出 SQL 或 CSV 才保留原始 UTC 值
跨库复制失败最常卡在字符集和约束上
哪怕结构看起来一样，复制表 或 SQL 导入 也可能静默失败或数据截断，根源往往藏在细节里：
- 源表字段是
VARCHAR(255) CHARACTER SET utf8mb4，目标库默认utf8→ 插入 emoji 或生僻字时被截断，日志可能只报Data too long不提编码 - 目标表有
NOT NULL字段，但源数据该列含NULL→ 复制中断，错误信息藏在底部状态栏滚动日志里，需手动展开看 - 外键或唯一索引冲突：源数据有重复值，目标表开了
UNIQUE约束 → 报Duplicate entry，但 DBeaver 默认不回滚整批，可能只跳过几行导致数据不全 - 真正保险的做法：先导出结构（
Export Schema），手动检查并修改目标建表语句中的字符集、约束、默认值，再导入数据
实际跨库搬运时，最省心的路径是：确认连接 → 右键 复制表 → 勾选“结构+数据”和“替换现有表” → 看底部日志是否出现 Completed successfully。所有看似绕路的导出导入步骤，其实都是为了绕开那几个藏得最深、报错最模糊的兼容性坑。
