导出DDL时必须预先指定目标数据库类型，否则会生成含ENGINE、AUTO_INCREMENT等源库专有语法的SQL，导致在目标库执行报错；正确做法是在“生成SQL→DDL”配置中选择目标库（如PostgreSQL），并勾选“转换数据类型”，DBeaver才会自动适配语法、剔除不支持子句、处理大小写及注释差异。
导出 DDL 时选错“目标数据库类型”会导致语法错误
DBeaver 的 生成SQL → DDL 功能默认按当前连接的数据库类型生成语句，比如从 MySQL 表导出，得到的是 CREATE TABLE ... ENGINE=InnoDB；若想迁移到 PostgreSQL，直接执行会报错——ENGINE、AUTO_INCREMENT、TIMESTAMP DEFAULT CURRENT_TIMESTAMP 这些都不是 PostgreSQL 语法。
关键不是“复制后手动改”，而是导出前就指定目标方言：
- 右键表 →
生成SQL → DDL - 弹窗中别急着点“完成”，先点右下角
配置按钮 - 在
目标数据库下拉菜单里，选你要转成的目标类型（如PostgreSQL或Oracle） - 勾选
转换数据类型（DBeaver 会把VARCHAR(50)映射为character varying(50)，INT→integer等）
此时生成的 DDL 才是目标库可直接执行的。不点这一步，后续只能靠肉眼一行行改，容易漏掉约束名、索引定义或默认值写法差异。
跨库建表时主键和自增字段最容易出兼容性问题
MySQL 的 id INT AUTO_INCREMENT PRIMARY KEY 在 PostgreSQL 中对应的是 id SERIAL PRIMARY KEY，而 Oracle 需要序列 + 触发器。DBeaver 能自动转换，但有前提：
- 源表必须有明确的主键定义（不能只靠索引隐式识别）
- 源字段类型要是标准 SQL 类型（比如用
INT而非TINYINT或MEDIUMINT，否则转换可能 fallback 成integer但精度丢失） - 如果源表用了 MySQL 特有属性（如
COMMENT 'xxx'），DBeaver 会保留注释，但 PostgreSQL 的注释语法是COMMENT ON COLUMN xxx IS 'xxx'——它不会自动拆成独立语句，得自己补
一个快速验证方法：导出 DDL 后，在目标库的 SQL 编辑器里粘贴并执行前，先扫一眼有没有 ENGINE=、AUTO_INCREMENT、DEFAULT CHARSET= 这类残留。有就说明目标类型没设对，或者 DBeaver 版本太老（21.3 之后才完善跨方言类型映射）。
DDL 转换后执行失败，大概率是字符集或排序规则没处理
MySQL 导出的 DDL 常带 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci，而 PostgreSQL 默认用 UTF8 编码，不认 COLLATE 子句（它用 LC_COLLATE 在数据库级设置）。直接执行会卡在 ERROR: unexpected character 或类似语法错误。
解决方式很简单：
- 导出前在
配置 → 目标数据库里选对类型，DBeaver 会自动剔除不支持的子句 - 如果仍看到字符集相关字段，手动删掉整段
CHARACTER SET ... COLLATE ...即可（PostgreSQL 表级不支持该语法） - 注意：MySQL 的
utf8mb4对应 PostgreSQL 的UTF8，二者语义一致，删掉不影响实际存储
另一个坑是大小写敏感。MySQL 默认不区分表名大小写（lower_case_table_names=1），PostgreSQL 全部小写且区分标识符大小写。如果源表名含大写字母（如 UserLog），DBeaver 转换后会自动加双引号："UserLog"。这点必须保留，否则目标库会找不到表。
批量转换多个表时，别依赖单表 DDL 导出再拼接
想把整个 MySQL schema 迁到 PostgreSQL？一个个右键导出再合并 SQL 文件效率低，还容易漏外键、索引、视图等对象。更稳的做法是用 DBeaver 的 数据库迁移向导：
- 菜单栏 →
工具 → 数据库迁移 - 选择源连接（MySQL）和目标连接（PostgreSQL）
- 勾选要迁移的对象类型（表、视图、索引、约束等）
- 点击
下一步后，它会预生成完整迁移脚本，并高亮所有需人工确认的转换点（比如 TEXT 字段在 PG 中是否要转成text还是varchar）
这个流程比手动拼 DDL 强得多：它能保证外键引用顺序、自动处理跨库函数替换（如 NOW() → CURRENT_TIMESTAMP）、甚至提示哪些 MySQL 特有功能（如全文索引）在目标库不支持。真正需要你动手的，只是最后几处语义等价但写法不同的地方。
DDL 转换最耗时间的从来不是语法本身，而是搞清哪些“看起来一样”的关键字在不同方言里行为其实不同——比如 NULL 约束、ON UPDATE CURRENT_TIMESTAMP、ENUM 类型。DBeaver 能覆盖 80% 的机械转换，剩下那 20%，得靠你对着目标库文档逐条核对。
