题干与适用场景
你负责一条本地分析任务，DuckDB 读取 Parquet 后执行多表 JOIN、GROUP BY 和窗口函数。数据量增长后，任务要么报 Out of Memory，要么在临时目录产生大量文件并超时。请说明排查顺序、参数调整、SQL 改写和验证办法。
适用场景包括数据工程、分析工程和嵌入式 OLAP 面试。回答应围绕可观测证据展开，不能只说“加内存”或“换更大的机器”。
面试官考察点
- 能否区分流式执行与需要保留大量状态的阻塞算子。
- 能否用执行计划、运行时画像和内存指标定位峰值，而不是凭感觉改参数。
- 是否理解线程数、内存上限、溢盘目录和插入顺序设置之间的关系。
- 是否会同时检查临时磁盘、权限、数据类型、索引和 JOIN 结果膨胀。
- 是否把正确性、可复现性和回归性能纳入调优闭环。
回答前需要澄清的问题
- OOM 发生在扫描、JOIN、聚合、排序还是窗口阶段？是 DuckDB 主动报错，还是操作系统杀进程？
- DuckDB 版本、运行线程数、
memory_limit、临时目录位置和可用磁盘空间是多少？ - 输入是否来自 Parquet/CSV，列类型和分区布局怎样？过滤条件能否下推？
- 查询是否有高基数 GROUP BY、精确 DISTINCT、宽 JOIN、ORDER BY、窗口、
list/string_agg或 PIVOT？ - 结果是否允许分批、预聚合、近似聚合或改变输出顺序？
30 秒回答框架
我先确认是哪个算子和哪一种资源耗尽，再用 EXPLAIN ANALYZE、内存快照和临时目录指标建立基线。若是高基数聚合、JOIN、排序或窗口造成的阻塞状态，我先减少扫描列和行、修正过滤与连接条件，再降低并发、设置合理内存上限并确认可用的溢盘目录。最后用固定样本和全量校验比较行数、键唯一性、聚合结果与延迟，确保优化没有改变语义。
分步骤深入解答
1. 先区分内存错误与临时磁盘故障
记录错误文本、进程退出原因、峰值 RSS、DuckDB 版本、线程数和查询指纹。DuckDB 默认把一部分可用内存作为上限，但操作系统 OOM、容器限制、临时目录不可写或磁盘已满，都会呈现相似症状。先验证 cgroup/容器限制、磁盘容量与权限，再决定是否调 SQL。
2. 从执行计划找到阻塞算子
用 EXPLAIN 查看连接顺序、过滤是否下推，用 EXPLAIN ANALYZE 查看实际行数、耗时和每个算子的运行状态。扫描通常按块流式处理；GROUP BY、JOIN、ORDER BY、窗口和精确 DISTINCT 需要保留哈希表、排序缓冲或窗口帧，数据基数上升时会形成峰值。若出现连接键错误导致行数乘法，先修复语义再谈内存。
3. 先减小工作集，再调资源
只读取必要列，尽早加入分区和时间过滤，避免在子查询中先构造全量宽表。把可复用的高成本事实做分区预聚合；将明显的多对多 JOIN 拆成带唯一性检查的步骤。高基数精确统计不能随意换成近似算法，必须先确认业务误差边界。
4. 设置并验证线程、内存和溢盘
线程越多，多个算子可能同时持有状态；在受限主机上可以先降低 threads。memory_limit 要低于容器可用内存，保留系统余量；只提高上限会把问题推迟到系统 OOM。需要溢盘时，确认临时目录在本地高速磁盘、可写且有足够额度。可用以下设置做一次受控实验：
SET threads = 4;
SET memory_limit = '4GB';
SET temp_directory = '/var/tmp/duckdb_swap';
SET preserve_insertion_order = false;
EXPLAIN ANALYZE
SELECT customer_id, date_trunc('day', event_time) AS day, sum(amount) AS total
FROM read_parquet('events/*.parquet')
WHERE event_time >= DATE '2026-01-01'
GROUP BY customer_id, day;preserve_insertion_order 只有在业务不依赖输入顺序时才可关闭。索引和某些中间状态不一定由缓冲管理器统一管理，不能把 memory_limit 当作所有内存的硬护栏。
5. 识别溢盘和算子限制
溢盘能处理很多大型 GROUP BY、JOIN、排序和窗口场景，但会增加 I/O。多个阻塞算子串联、超大的列表聚合、string_agg、某些 holistic aggregate 和 PIVOT 可能仍需要大量不可分割状态。若临时目录增长异常，检查 temp_directory、max_temp_directory_size、磁盘吞吐和清理策略；溢盘不可用时应回到分批读取或 SQL 重写。
6. 用结果与性能双重回归收口
固定输入快照，比较优化前后的总行数、主键集合、NULL 分布、分组计数、金额校验和以及抽样明细。记录峰值内存、临时字节数、扫描字节数、耗时和失败率。对边界日期、空分区、重复键和极端高基数样本单独验证，避免只在平均数据上看到成功。
高质量示范回答
我会先把问题归类为算子状态、配置资源或外部环境三类。第一步保存版本、查询、输入快照、容器内存和临时盘证据，用 EXPLAIN ANALYZE 定位实际峰值。若是高基数 GROUP BY、错误的多对多 JOIN、排序或窗口，我先检查基数和过滤下推，减少列和行，必要时分区预聚合；不会用增大 memory_limit 掩盖连接膨胀。
随后在受控环境把线程数降到可承受范围，给 memory_limit 留出系统余量，并把 temp_directory 放到容量和权限都明确的磁盘。只有输入顺序不属于业务语义时才关闭 preserve_insertion_order。我会记录内存峰值、溢盘量和耗时，确认临时文件没有超过额度。对于无法有效拆分的列表聚合、超大字符串聚合或 PIVOT，我会改成分阶段结果或重新评估查询形状。
最后用固定样本和全量数据比较行数、键唯一性、聚合校验和、边界分区及 NULL 行为，再决定是否上线。这样既能证明 OOM 消失，也能证明结果语义没有被“优化”改变。
常见错误
只增加 memory_limit
没有先确认容器限制、系统余量和非缓冲管理内存，可能从 DuckDB OOM 变成操作系统 OOM。
把所有算子都当成可溢盘
应确认具体算子和版本支持；某些列表、字符串、holistic 聚合与 PIVOT 仍可能需要不可分割的内存状态。
忽略 JOIN 基数和过滤下推
连接键不唯一或过滤太晚会制造数量级更大的中间结果，参数调整无法修复错误的查询形状。
只看查询成功，不做结果回归
关闭顺序保持、拆分聚合或改用近似算法都可能改变语义，必须用固定样本和业务校验比较。
追问及应对
追问一：为什么降低线程数可能有效？
并发执行的算子会同时保留状态和缓冲，降低线程数可降低峰值，但通常会牺牲吞吐。应以峰值内存和完成时间的实测曲线确定值，而非固定套用。
追问二：临时目录有空间，为什么仍然 OOM？
不是所有状态都能拆分溢盘；不可分割的聚合、过大的连接状态或临时目录权限/额度问题仍会失败。要结合计划、算子限制和错误日志判断。
追问三：什么时候可以关闭插入顺序保持？
只有结果不依赖输入顺序、下游也不把顺序当作契约时。关闭后应在回归中验证重复键、排序和 LIMIT 相关行为。
追问四：怎样证明调优没有改变结果？
使用同一输入快照，对比行数、主键集合、分组计数、数值校验和、NULL 分布及边界分区；对近似聚合则明确误差预算并取得业务认可。