DBeaver 导出大表时如何避免一次性加载内存

DBeaver 导出大表时，关键不是把结果网格一次性全部加载出来，而是让 Data Transfer 直接从数据库读取，并把读取批次、分段方式和文件编码设清楚。实际操作中优先选 CSV，使用 Query the database，把 Fetch size 控制在一个温和的范围；数据量再大时启用分段提取。这样可以降低客户端瞬时内存压力，代价是导出时间会更依赖数据库、磁盘和网络速度。

官方地址：https://dbeaver.com/

步骤一：从表或查询结果打开 Export Data

在左侧 Connections 中找到目标表，右键选择 Export Data。如果前面已经写好了带筛选条件的 SQL，也可以在结果网格中右键选择 Export data。两条入口最终都会进入 Data Transfer 向导。

大表建议在向导的格式列表中选择 CSV。XLSX 更适合交付给少量数据的业务同事，整表规模很大时，CSV 更容易连续写入、拆分和后处理。进入下一步后，先检查列清单，避免把不需要的宽字段、调试字段也导出。

步骤二：把提取方式改为可控的批次

在 Extraction settings 中选择 Query the database，让导出任务直接从数据库取数。不要为了省一步而选择 Use fetched rows：它依赖结果集里已经取到的数据，之前为了浏览表格加载的内容并不等于完整导出范围。

先把 Fetch size 设为 5000 左右作为起点。它表示驱动每批取回的行数，不是最终文件大小；网络延迟高、单行字段窄时可以逐步上调，行里有大文本或二进制字段时则要下调。对特别大的表，把 Extract type 改成 Multiple queries，再设置 Segment size，例如 100000 行一段。分段值不是越大越好，重点是让单段耗时和内存都可控。

步骤三：按需处理连接和行数统计

如果导出期间还要继续查询同一个数据库，勾选 Open new connection(s)，让读取任务使用新的物理连接。连接数和数据库并发能力有关，单表导出通常不需要为了“更快”盲目增加线程。

Select row count 会在导出前先查询行数，确实需要完整进度信息时再保留它。对复杂视图、分区表或带过滤条件的大表，这个额外统计可能先消耗一次查询资源；只想拿到文件时可以取消。完成这一组设置后，确认向导仍然显示正确的表名和列范围。

步骤四：确认 CSV 编码和字段格式

进入 CSV 的格式设置，编码选 UTF-8，再核对分隔符、是否写入列名、NULL 值的表示方式和文本引用规则。中文内容出现乱码，往往不是内存问题，而是导出编码与打开文件的软件默认编码不一致。

文件名可写成 orders_20260912.csv 这类可追溯形式。不要把“导出向导已经关闭”当成成功条件；真正要确认的是任务完成，以及目标目录出现可读取的结果文件。

步骤五：等待后台任务并抽样验收

点击完成后，DBeaver 会在后台执行数据传输。观察任务进度区中的读取、写入和错误状态，出现失败时先看具体阶段：连接失败、权限不足、磁盘空间不足和字段编码问题的处理方向完全不同。

任务显示 completed 后，打开 CSV 检查三件事：第一行的列名是否完整；中间抽样记录的分隔列数是否稳定；文件末尾是否有被截断的引号或半行。需要精确数量时再与源查询的统计结果对比。验收通过后再把文件交给下游，不要在任务仍为 running 时复制半成品。

常见问题

DBeaver 的 Fetch size 越大越省内存吗？

不是。它只是改变单批从驱动取回的行数；批次越大通常减少往返次数，但可能增加瞬时内存和等待时间，应结合单行大小逐步调整。

为什么导出任务完成了，文件却比预期小？

先检查是否误用了 Use fetched rows、是否只选中了部分列或设置了筛选条件，再核对任务错误信息和文件末尾，不能只根据文件大小判断完整性。

什么时候应该选择 Multiple queries？

当单次提取耗时过长、表规模很大或需要把读取拆成更可控的段时再用。先确认排序键、过滤条件和数据库对分段查询的支持，避免把分段当成无条件提速开关。

这套配置的核心是把“浏览结果”和“导出整表”分开：由数据库直接供数，DBeaver 负责按批读取并连续写文件，最后用任务状态和文件抽样完成确认。