直接调大-Xmx参数不保证有效，因DBeaver内存消耗包含JDBC驱动、元数据缓存、字段解析、结果集对象及格式转换等多重开销，实际堆占用可达原始数据3–5倍；需配合-Xms512m、-XX:+UseG1GC等完整调优，并清理缓存、禁用冗余驱动、分页导出及选用CSV格式。
直接调大 -Xmx 参数不保证有效，甚至可能让问题更隐蔽——关键得看 DBeaver 是怎么用内存的。
为什么改了 -Xmx 还报 Java heap space
DBeaver 不是简单地把查询结果塞进堆里就完事。它要加载 JDBC 驱动、缓存元数据、解析每行字段类型、维护结果集对象引用、再转成 CSV/Excel 格式……这些加起来远超你预估的数据体积。比如导出 100 万行 VARCHAR(200) 的数据，实际堆内对象开销可能是原始文本大小的 3–5 倍。
-
-Xmx只控制最大堆上限，但默认的-Xms（初始堆）太小（常为64m），导致频繁 GC 和内存碎片 - 没启用
-XX:+UseG1GC时，老年代回收效率低，大结果集容易触发 Full GC 失败 - Mac/Linux 用户常改错文件：
dbeaver.ini在应用包内（右键 → 显示包内容 → Contents → Resources → app → dbeaver.ini），不是用户目录下的配置
dbeaver.ini 必须改的三行参数
别只动 -Xmx。以下配置针对 8GB 物理内存机器实测稳定（导出 50 万行 CSV 无卡顿）：
-vmargs -XX:+UseG1GC -Xms512m -Xmx2048m
-
-Xms512m：避免启动后反复扩容堆，减少早期 GC 次数 -
-Xmx2048m：不超过物理内存 50%，留足空间给操作系统和其他插件 -
-XX:+UseG1GC：G1 收集器对大堆更友好，配合-XX:MaxGCPauseMillis=200可选加，但非必需
改完必须彻底退出 DBeaver（macOS 要在 Dock 中右键退出，不能只关窗口），否则无效。
立即学习“Java免费学习笔记（深入）”；
导大数据时真正省内存的做法
光调 JVM 参数是“硬扛”，遇到百万级数据仍大概率失败。更可靠的是绕过全量加载：
- 导出前先用
SELECT COUNT(*) FROM table看总量，超 50 万就别直导 - 用分页 SQL 替代全表导出：
SELECT * FROM table ORDER BY id LIMIT 100000 OFFSET 0，导完再改OFFSET - 禁用不需要的驱动：进
窗口 > 首选项 > DBeaver > 驱动，只留当前用的数据库类型，每个未禁用驱动平均多占 80–120MB 堆 - 导出格式选
CSV或TSV，别选Excel (.xlsx)—— Apache POI 库生成 Excel 的内存开销是 CSV 的 4 倍以上
容易被忽略的缓存陷阱
很多人忘了 DBeaver 会缓存结果集和元数据。即使你没手动点“缓存”，只要执行过查询，这些数据就留在堆里：
- 导出前右键结果集 →
清理结果集，强制释放引用 - 定期执行
数据库 > 清理连接缓存，尤其在切换不同库或表结构变更后 - 如果长期只查固定几张表，可在
窗口 > 首选项 > 数据库 > 元数据中把缓存元数据关掉
缓存不清理，连续导三次 20 万行数据，堆占用可能比单次导 60 万还高——因为三份元数据+三份结果集对象同时存在。
