你好呀！我特别理解你遇到这个问题的头疼——本来想分批取数控制内存，结果原生客户端偷偷把全表加载进来了，确实挺闹心的。我来给你拆解下背后的原因，以及目前的可行方案：

一、原生客户端内存暴增的核心原因 #

这其实是当前DuckDB R原生客户端的默认实现逻辑，并不是你漏了什么配置哦！

DuckDB的R客户端在执行dbSendQuery时，会默认把整个查询结果预加载到R环境的结果集对象（也就是你发现的rs@env$resultset）里，这个设计是为了给那些需要直接获取全量结果的场景做性能优化，但反过来就导致了批量取数时的内存浪费——哪怕你打算分批dbFetch，全量数据已经先被塞进内存了。

而Python客户端的实现逻辑完全不同，它是真正的流式取数：查询执行后只保留结果集的游标位置，每次fetchone/fetchmany才从数据库拉取对应批次的数据，不会预加载全量结果，所以内存占用一直很低。

二、ODBC驱动能正常工作的原因 #

你用ODBC驱动的方式能达到低内存占用，是因为ODBC协议本身就是基于游标流式取数的规范，DuckDB的ODBC驱动严格遵循了这个逻辑：它不会把全量结果预加载到R内存里，只会在你调用dbFetch时拉取指定批次的数据，所以内存 footprint 完全符合你的预期。

你贴的ODBC配置和代码示例也没问题，这个workaround确实是目前兼顾低内存和DuckDB访问的好办法。

三、原生客户端有没有配置可以调整？ #

截至DuckDB R客户端v0.9.x版本，没有公开的配置项可以关闭预加载全量结果的行为。不过你可以关注这两个方向：

• 可以去DuckDB官方仓库的Issues区看看，已经有不少用户反馈过类似问题，开发团队有可能在后续版本中增加流式取数的配置开关；
• 如果必须用到原生客户端的独有功能（比如duckdb_register），可以尝试先把大表拆分成小的临时表，再分批查询临时表；或者用duckdb_execute把查询结果导出成分块的Parquet/CSV文件，再用R的arrow/readr包分批读取本地文件；

四、补充的临时解决方案 #

除了你已经用的ODBC方式，还有两个思路可以试试：

1. 手动范围分页查询：如果表有有序的主键或者字段，可以用WHERE条件做范围分页，比如：

last_id <- 0
repeat {
  x <- dbGetQuery(con, sprintf("SELECT * FROM big_table WHERE id > %d LIMIT 1e5", last_id))
  if (nrow(x) == 0) break
  # 处理数据...
  last_id <- max(x$id)
}

这种方式避免了预加载全量结果；要注意大表用OFFSET分页会有性能问题，范围分页更高效；

2. 利用DuckDB的导出功能：先把查询结果导出成分块文件，比如：

duckdb_execute(con, "COPY (SELECT * FROM big_table) TO 'temp_data_' (FORMAT PARQUET, PARTITION_BY 'partition_col')")

然后用arrow::open_dataset读取分块文件，逐块处理，内存占用也会很低；

如果后续DuckDB R客户端更新了流式取数的配置，我会第一时间关注，你也可以给官方提Issue催催更哦！