导出卡死或内存爆掉的根本原因是未分批处理50万行以上数据，DBeaver全量缓存结果集导致查询阶段JDBC压力过大；应前置查总数、单次≤10万行、用WHERE+LIMIT手动分页，并避免误信Batch Size参数。
导出时卡死或内存爆掉，本质是没分批
50 万行以上数据直接“全表导出”，DBeaver 默认会尝试把整个结果集缓存在内存里做格式转换——哪怕你选的是 XLSX，底层流式写入（SXSSFWorkbook）也挡不住查询阶段的 JDBC ResultSet 拉取压力。真正卡住的环节往往不是写 Excel，而是数据库返回数据太慢、超时，或者 DBeaver 在组装中间结果时堆内存撑爆。
- 查总行数必须前置：
SELECT COUNT(*) FROM your_table，别靠肉眼估算 - 单次导出建议上限：≤ 10 万行；超过就拆，这是硬经验，不是建议
- 不要依赖“流式写入开启”就高枕无忧——它只管写文件那一步，不管你怎么查数据
手动分页导出：用 WHERE + LIMIT 写 SQL 控制批次
这是最可控、兼容所有数据库的方式。DBeaver 的“导出数据”功能本身不提供自动分页，但你可以把分页逻辑写进 SQL 里，再对每个结果集单独导出。
- 先确认主键或时间字段可排序（比如
id或create_time），否则分页不可靠 - 示例（MySQL/PostgreSQL）：
SELECT * FROM orders WHERE id BETWEEN 1 AND 10000 ORDER BY id - 下一批改写成：
SELECT * FROM orders WHERE id BETWEEN 10001 AND 20000 ORDER BY id - 导出时务必勾选“包含列头”，否则合并文件时表头错位
导出向导里的 Batch Size 是假的“分批”
Batch Size 参数（默认 1000）只影响 DBeaver 从 JDBC ResultSet 中 fetch 数据的批次大小，**不是导出文件的分卷逻辑**。它对内存缓解作用有限，尤其当字段含大文本或 BLOB 时，每行实际内存占用远超行数乘以列数。
- 这个值调到 5000 以上反而可能触发驱动层缓冲膨胀，不推荐盲目加大
- 它不影响最终生成几个文件，只影响拉数据时的网络包和内存抖动频率
- 真正要“分卷”，得靠上一步的手动 SQL 分页，或启用多线程并行导出（见下条）
多线程并行导出：适合有唯一递增 ID 的表
DBeaver 支持在导出向导高级设置里开启并行，但它要求你提前把数据逻辑切分成多个不重叠的区间，并为每个区间建独立查询。不是点个开关就自动分片。
- 操作路径：SQL 编辑器执行完查询 → 右键结果集 → “导出数据” → “高级”页 → 勾选“启用并行处理”
- 必须配合 WHERE 条件使用，例如开 4 个线程，就准备 4 条 SQL：
WHERE id % 4 = 0、WHERE id % 4 = 1…… - 注意：
id % N方式在 ID 不连续或有空洞时会导致漏数据，生产环境优先用BETWEEN+ 范围预估 - 导出文件名会自动加序号（如
table_001.xlsx），但需自己后期合并或标注批次边界
分卷导出真正的复杂点不在按钮怎么点，而在于你是否清楚数据分布特征——ID 是否稀疏、时间字段是否均匀、有没有 NULL 值干扰范围切割。这些细节不摸清，光调参数只会让问题延迟爆发。
