MonetDB 11.39.11升级至11.41.5后COPY INTO内存占用过高问题

核心改动点（11.39.11 → 11.41.5） #

两个版本迭代过程中，COPY INTO语句的实现逻辑共有两处直接影响内存占用的调整：

• 预校验逻辑变更：11.39.11版本采用流式批处理模式，每读取10万~100万行（默认阈值）就完成数据校验、类型转换后直接刷入磁盘，批次内存占用被严格限制，因此2.25亿行数据仅需16GB内存即可完成导入。11.41.5版本为了降低导入失败率、提前识别全量数据的格式问题，新增了全量文件预扫描逻辑，默认会先读取整个文件的所有行完成非空约束、字段类型一致性校验，校验完成后才启动写入流程，2.25亿行规模的文件预扫描阶段就会加载全量字段元数据到内存，直接导致内存占满。
• 可变长字段内存分配策略调整：旧版本导入字符串等可变长类型字段时，采用分段动态分配内存的策略，每批次写入完成后立即释放临时缓冲区。11.41.5版本为了优化导入后字符串列的查询性能，会在导入阶段预计算所有可变长字段的总长度，一次性申请连续内存块存储全量可变长数据，对于包含多个字符串字段的40列宽表，预分配内存可达源文件总大小的1.2~1.5倍，远超16GB的内存阈值。

可行解决方法 #

• 显式关闭全量预扫描逻辑，在COPY INTO语句中添加BEST_EFFORT参数，即可回退到旧版本的流式导入逻辑，内存占用可恢复到11.39.11版本的水平，示例语法：

COPY INTO 你的事实表名
FROM '/path/to/你的数据源文件.csv'
DELIMITER ',' 
BEST_EFFORT;

注意开启该参数后，导入过程中如果遇到不符合约束的数据会直接终止任务，建议导入前提前做好源文件的格式校验。

• 拆分导入任务，通过添加OFFSET和COUNT参数将2.25亿行数据拆分为多批次导入，每批次控制在1000万~2000万行，导入完成一批再执行下一批，也可有效控制内存峰值。

内容的提问来源于stack exchange，提问作者Llorieb