SQL Trino 的 spill-to-disk 与内存溢出查询优化实践

trino的spill-to-disk需显式配置且依赖合理资源划分，非自动兜底；oom主因是单stage内存分配不当或shuffle/聚合未优化，须同步启用spill参数、调优内存与并发设置，并验证spilled data生效。

Trino 的 spill-to-disk 功能不是“自动兜底”，而是需要显式配置 + 合理资源划分才能生效；内存溢出（Query exceeded per-node user memory limit）往往不是因为数据太大，而是因为单个 stage 内存分配不合理或 shuffle/聚合逻辑未优化。

spill-to-disk 不是默认开启的，必须主动启用

Trino 默认禁用 spill，即使磁盘空间充足，查询仍会直接 OOM。需在 coordinator 和 worker 的 config.properties 中同时设置：

• experimental.spill-enabled=true
• experimental.spiller-spill-path=/path/to/spill/dir（确保路径存在、可读写、有足够空间）
• experimental.max-spill-per-node=20GB（建议设为物理内存的 30%~50%，避免抢占 jvm 堆）

注意：spill 路径不能是 NFS 或低 IOPS 存储，否则反而拖慢查询；多个 worker 应使用本地盘，不要共用同一挂载点。

内存溢出常见诱因与针对性调优

多数 OOM 并非源于总数据量，而是局部操作（如大表 join、group by 高基维、窗口函数全排序）导致单节点内存陡增：

• Join 倾斜：用 /*+ REPARTITION */ 强制重分布，或对倾斜 key 单独处理（如拆出 NULL/热点值先过滤）
• GroupBy 高基数：检查是否误用 GROUP BY * 或包含高唯一值列（如 uuid）；可加 approx_distinct() 替代精确去重
• Window 函数未限制范围：避免 ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING，改用 ROWS BETWEEN 100 PRECEDING AND CURRENT ROW
• 小文件过多：合并 Parquet 小文件（如用 hive compaction），减少 task 数量和元数据开销

关键参数协同调整策略

仅开 spill 不够，还需平衡内存预算与并发压力：

• query.max-memory-per-node=8GB：设为 JVM 堆的 60%~70%，留足空间给 spill buffer 和 JVM 开销
• query.max-total-memory-per-node=12GB：必须 ≥ max-memory-per-node + max-spill-per-node，否则 spill 无法触发
• task.concurrency=4：降低并发数可减少 peak memory，尤其对 hash aggregation/join 有效
• optimizer.optimize-hash-generation=true：开启后减少 hash 表内存占用（v390+ 默认 true）

验证是否生效：查 sys.stage_stats 或 Web UI 的 “Spilled Data” 列，非零即表示 spill 已参与执行。

实战诊断三步法

遇到 OOM 时快速定位瓶颈：

• 看失败 stage 的 operator Stats：重点关注 HashBuilder、HashProbe、TopN 等 operator 的 Peak Memory
• 查 EXPLAIN (TYPE DISTRIBUTED) 输出：观察是否有 broadcast join 被误用（小表实际很大）、partitioning key 是否合理
• 用 select * FROM system.runtime.queries WHERE state = 'FAILED' 提取 error_message 和 resource_group_id，确认是否被资源组限流

真正稳定的 spill 实践，核心是让内存压力“可预测、可分流、可退让”，而不是依赖磁盘兜底扛所有负载。