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 实践，核心是让内存压力“可预测、可分流、可退让”，而不是依赖磁盘兜底扛所有负载。
