直接调大-Xmx参数治标不治本，有效解法是分层排查：确认是否JVM堆内存不足、结果集加载策略不合理或插件缓存堆积；dbeaver.ini须位于安装目录且参数写在-vmargs后、其他JVM参数前；-Xms设为-Xmx的1/3～1/2并启用-XX:+UseG1GC；Mac需用终端命令启动；导入导出应优先流式执行、分页分批、禁用冗余选项；缓存需限时清理，避免结果页和线程堆积。
直接调大 -Xmx 参数能缓解大部分 OutOfMemoryError，但治标不治本；真正有效的解法是分层排查：先确认是 JVM 堆内存不足、还是结果集加载策略不合理、或是插件缓存堆积导致的隐式泄漏。
怎么改 dbeaver.ini 才算有效
修改位置必须是 DBeaver 安装目录下的 dbeaver.ini（不是用户配置目录里的文件），且参数要写在 -vmargs 之后、其他 JVM 参数之前。常见错误是改错文件或加在了注释行后面，导致参数根本没生效。
-
-Xms建议设为-Xmx的 1/3～1/2，比如-Xmx4g对应-Xms1536m，避免频繁扩容触发 GC - 必须加上
-XX:+UseG1GC，DBeaver 在大数据量场景下用 G1 垃圾回收器比默认的 Parallel 更稳 - Mac 用户注意：如果从 Launchpad 启动，系统可能忽略
dbeaver.ini，需改用终端命令启动：open -a "DBeaver" --args -vmargs -Xmx4g
导入大 SQL 或 CSV 时卡死或报 OutOfMemoryError: Java heap space
这不是单纯加内存能解决的问题——DBeaver 默认把整个文件读进内存解析语法、构建执行计划，GB 级文件直接压垮堆空间。
- 优先用「执行 Script」功能（右键 SQL 文件 → Execute Script），它走流式执行，不全量加载
- 避免用「导入向导」导入 >100MB 的 CSV；换成数据库原生命令，比如 PostgreSQL 用
COPY，MySQL 用LOAD DATA INFILE - 如果必须用 GUI 导入，勾选「分批提交」并把批次大小限制在 1000 行以内，同时关闭「自动提交」
导出大表时卡在 Writing data... 或崩溃
导出过程默认把整张表查出来再写文件，百万行以上极易触发 OutOfMemoryError，尤其当字段含 TEXT、JSON 等大类型时。
- 在导出向导中启用「分页导出」，每页限制 5000 行以内，并勾选「使用服务器端游标」（PostgreSQL/MySQL 8.0+ 支持）
- 禁用「导出 DDL」和「导出元数据」选项，这两项会额外加载大量 schema 信息到内存
- 检查目标格式：导出为
.csv比.xlsx内存开销低一个数量级；Excel 格式会把全部数据缓存在内存里建 workbook 对象
内存占用持续上涨，重启后又很快飙高
这大概率不是堆内存配置问题，而是插件缓存或驱动加载失控。DBeaver 的 MaterializeSchemaCache 和 PostgreDataTypeCache 在频繁切换库或执行 SELECT * 后会累积不释放。
- 窗口 → 首选项 →
DBeaver→Metadata→ 把Metadata cache max age设为3600000（1 小时） - 同路径下关闭
Save metadata in workspace，防止缓存写入磁盘后反复加载 - 删除
~/.dbeaver4/.metadata/.plugins/org.jkiss.dbeaver.core/下的cache子目录（Linux/macOS）或%APPDATA%\DBeaverData\.metadata\.plugins\org.jkiss.dbeaver.core\cache（Windows）
最常被忽略的一点：JVM 参数调得再高，如果禁用了「服务器端游标」或开着几十个未关闭的查询结果页，内存照样会撑爆。观察 Activity Monitor（Mac）或 任务管理器 中的线程数，超过 200 个活跃线程基本可以判定是结果集没释放。
