2026 服务器租用联邦查询引擎 Trino 落地全解：内存池、连接器与谓词下推六维对比 + 避坑避雷手册

2026 服务器租用联邦查询引擎 Trino 落地全解：内存池、连接器与谓词下推六维对比 + 避坑避雷手册

把 Trino 装上服务器这事，技术门槛其实不高——解压、改几个 config、跑起来，半天能搞定。真正让人栽跟头的是装上之后：同样一句 SQL，昨天 3 秒今天 40 秒；并发一上到 12 个查询就开始报内存超限，而且不是慢，是直接死；明明在 Hive 上跑得飞快的一条过滤，换个 MySQL 数据源就变成全表扫描。这些现象背后的原因各不相同，但都指向同一件事——Trino 的资源模型和你熟悉的那些数据库不是一回事。

我自己踩过的最大一个坑是拿它当"能同时查所有库的神器"用，结果把三张千万级的表跨源 join 了一下，直接把 coordinator 拖死。后来才明白，Trino 的能力边界不在"能不能查到"，而在"内存够不够、下推推不推得下去"。下面这些内容，都是围绕这条主线展开的：内存池怎么切、连接器到底差在哪、谓词下推在什么写法下会断。

先把最要紧的几条摆出来：

1. Trino 是纯内存流水线，中间结果不落盘（除 fault-tolerant execution 外），内存就是它的磁盘——容量规划的方式和 MySQL、ClickHouse 完全不同。

2. 内存不够时不是变慢，是直接报 Query exceeded per-node memory limit——"硬失败"特性决定了你必须按峰值而不是均值去配内存。

3. 同一个 SQL 走 Hive/Iceberg 读 Parquet 和走 JDBC 读 MySQL，代价差一个数量级——连接器才是真正的性能变量，不是 CPU。

4. JDBC 连接器默认不自动做全量下推，jdbc.pushdown.* 是一组独立的开关——而且聚合下推和谓词下推是两个开关，开一个不等于开了另一个。

5. 缺 ANALYZE 统计信息会让 join 顺序选错——优化器可能把一张 3 亿行的表当小表广播出去，内存瞬间见底。

Trino 的内存池到底切成了几块：Coordinator 与 Worker 各管什么

Coordinator 与 Worker 的分工

Trino 集群的进程角色只有两种：一个 Coordinator，若干 Worker。Coordinator 干的是解析 SQL、做语法与语义分析、生成分布式执行计划、把计划切成 stage 和 task、再把 task 调度到 Worker 上去、最后跟踪每个查询的状态和心跳。它不参与实际的数据计算。Worker 干的是执行——从存储里读 split、做过滤、做 join、做聚合、把中间结果通过网络传给下游 stage。

这个分工有个直接后果：Coordinator 的负载和"查询的复杂度"强相关，和"查询的数据量"弱相关。一句带 40 个 join 的 SQL，即使只返回 10 行，Coordinator 也要花几百毫秒去规划，并且把整棵查询树的状态常驻在堆里。所以 Coordinator 单点挂掉时，正在跑的所有查询全部失败，客户端要重连重试；历史查询也没有持久化，重启即丢。

堆内存的三个分区

Trino 的 JVM 堆被切成三块，理解这三块是做容量规划的前提：

第一块是用户内存（user memory），由 query.max-memory-per-node 控制。它记的是那些和查询语义直接相关的开销——聚合用的 hash 表、join 的 build side、排序用的缓冲区。默认取 JVM 最大堆的 30%。

第二块是用户内存加系统内存（user + system memory），由 query.max-total-memory-per-node 控制。系统内存指的是 Trino 内部实现相关的开销，比如 shuffle 用的输出缓冲区、page 的序列化反序列化中间态。默认取堆的 60%。

第三块是堆预留（headroom），由 memory.heap-headroom-per-node 控制，默认堆的 30%。这一块不分配给任何查询，专门留给 JVM 自身的 GC 开销、第三方类库的临时对象、以及 Trino 在处理超大 page 时的瞬时峰值。

这三块加起来刚好等于堆。这个设计的意思是：你在配置里把 query.max-memory-per-node 往上调，实际上是在挤压 headroom，调到极端就会出现"查询没超限但 JVM 直接 OOM 崩了"。我见过有人把 heap 开 80G、把 per-node 上限开到 70G，结果 GC 一上来就没地方腾挪，进程被系统 kill。合理的比例是让 headroom 至少留到 25%–30%。

为什么 Trino 的查询不是变慢而是直接失败

这一点是很多人从 MySQL、ClickHouse 转过来最不适应的地方。传统数据库内存不够的时候会落盘——MySQL 的临时表写到磁盘，ClickHouse 有 external aggregation，慢是慢，但能出结果。Trino 不一样，它的执行模型是无落盘的流水线：上游 task 一边算一边把 page 推给下游，下游一边收一边算，整条链路上任何一个算子要申请内存而内存池没有额度了，它不会等，也不会溢写，而是直接让整个查询失败。

报出来的信息通常是这几种之一：Query exceeded per-node user memory limit of XX、Query exceeded per-node total memory limit of XX、Query exceeded distributed user memory limit of XX、或者 Query killed because the cluster is out of memory。前两个是单节点的，第三个是集群维度的累计用户内存，第四个是集群内存池满了之后被 killer 主动杀掉的。

这个"硬失败"特性直接改变容量规划的思路：你要按并发峰值去算内存，不能按均值。举个例子，一个 8 Worker 的集群，每台 256G 内存，堆开 160G，per-node 用户内存上限默认就是 48G。如果你日常跑的报表查询单个峰值 15G，看起来很宽裕，能跑 3 个并发。但真实情况是——查询的峰值不是均匀分布在整个生命周期里的，一句 SQL 可能前 30 秒在做 scan（内存 5G），中间 10 秒在做大表 join 的 build（内存瞬间冲到 35G），最后 5 秒在排序（20G）。两个查询的峰值如果撞在同一个时间窗里，75G 的需求就会撞到 48G × 某台节点的墙，两台同时爆。

所以我的经验是：单节点 per-node 上限要按"单查询峰值 × 1.5"来留，并发数靠资源组去卡，而不是靠让查询互相挤。宁可让第 4 个查询在队列里排 20 秒，也不要让 4 个查询一起跑到一半然后全部失败——失败的查询重跑一次的代价，远大于排队等一会儿。

memory.heap-headroom-per-node 为什么要留出来，以及大查询被 kill 的顺序

先说 headroom。Trino 判断"内存池还有没有额度"是按查询申请的实时统计来的，但这个统计有滞后——JVM 里那个对象还没被 GC 掉、Trino 这边已经算成释放了，或者反过来，一次大的 page 反序列化瞬间申请几百 MB，Trino 的计数器来不及记账。headroom 就是给这类"账面误差"兜底的。留太少，会出现节点没报超限但堆被吃满、Full GC 长时间 STW、心跳超时被 coordinator 判定节点失联，然后整个集群的查询一起失败，比单个查询失败严重得多。

再说 kill 顺序。当集群的通用内存池（general memory pool）被占满、没有任何 task 能拿到额度继续往下走的时候，Trino 会主动杀掉一些查询来腾空间，策略由 query.low-memory-killer.policy 决定，有两个值：

total-reservation-on-blocked（默认）：只有当集群里确实有 task 因为拿不到内存而进入 blocked 状态时，才启动 killer，杀掉当前总预留量最大的那个查询。这个策略比较克制，只有在真的卡住了才动手。缺点是它一动手就是杀最大的，如果你那句跑了 20 分钟的大报表刚好是最大的，每次都是它倒霉。

total-reservation：只要集群内存池的使用量超过一定水位就开始杀，同样是杀预留最大的。这个策略更激进，好处是能更早腾出空间，避免整池卡死，代价是误杀率上升。

还有一个值是 none，表示不启用 killer。我不建议在生产上用 none——关掉之后内存池满时集群会进入完全阻塞状态，所有查询都卡着不动，只能人工去 kill，恢复时间不可控。生产上留着 killer，配合资源组把大查询隔离到单独的组里，是更稳的做法。

资源组 resource groups 怎么把并发与内存配额切开

资源组是 Coordinator 上的一套配额机制，用来回答"谁能在什么时候跑几个查询、每个查询最多吃多少内存"。它有两种实现：配置文件（file，改完要重启或热加载 JSON）和数据库（database，改了立刻生效，适合动态场景）。配置按 selector 匹配——可以按用户名、按来源 IP、按客户端 tag、按查询类型把请求路由到不同组。

一个组里要设的关键项有这几个：

hardConcurrencyLimit：同时运行查询数的硬上限，超了就排队。maxQueued：最多允许多少个查询在队列里等，超了直接拒绝，避免队列无限增长把 coordinator 拖垮。memoryLimit：这个组能用的集群总内存的比例，比如 60%。queryMemoryLimit（旧称，新版用 softMemoryLimit 与 maxMemory 配合）：单个查询的内存上限，超了会被降级或杀掉。schedulingPolicy：组内多个查询怎么分配执行时间片，fair 是公平轮转，weighted 按权重，query_priority 按优先级。

一个典型的切法是三组：一组给 BI 的交互式查询，并发 20、内存占比 30%、单查询 8G，追求低延迟；一组给定时报表，并发 3、内存占比 50%、单查询 40G，能跑久一点；一组给 ETL 和临时即席，并发 5、内存占比 20%、单查询 15G，允许被前两组挤。这样切完之后，最大的好处是定时报表那句吃 40G 的大 SQL 不会把交互式的 20 个查询全部拖死——它最多吃自己那 50%，超了就在自己组里等。

连接器才是真正的性能变量：一句 SQL 在两个世界里的两种命运

这是本篇最想讲清楚的一点。很多人调 Trino 的第一步是加 CPU、加内存，其实优先级排错了。同样的 SQL，走 Hive/Iceberg 连接器读 Parquet/ORC，和走 JDBC 连接器读 MySQL，代价差一个数量级——不是慢 20%，是慢十倍甚至更多，而且失败方式都不一样。

差在哪？差在"有多少工作被推到数据源去做"。

走 Hive/Iceberg 时，Trino 读的是列式文件。它先拿元数据（Hive metastore 或 Iceberg 的 manifest）做分区裁剪——WHERE dt BETWEEN '2026-09-01' AND '2026-09-07' 这种条件下，7 天的分区直接从 1 万个候选分区里被挑出来，剩下的 9993 个连文件列表都不会去读。然后做列裁剪——一张 120 列的表你只 SELECT 8 列，Parquet 只会去读这 8 列的 column chunk，其余 112 列的字节根本不落进网络。最后做谓词下推到文件内部——Parquet 每个 row group、ORC 每个 stripe 都带 min/max 统计，amount > 5000 这种条件可以让整个 row group 被跳过，连解压都不用。三道过滤叠下来，扫描 40 亿行的表可能实际只碰了 2 亿行、读了 30G 而不是 800G。

走 JDBC 时，前面两道基本失效。JDBC 连接器面对的是 MySQL 的一张行存表，它拿不到"这一列在这个文件块里的取值范围"，也拿不到分区级元数据（MySQL 的分区表对 Trino 来说就是一张普通表）。它能做的只有一件事：把 WHERE 条件拼进 SQL 发给源库。如果条件拼成功了，MySQL 用自己的索引去查，也不慢；但拼不成功——比如你在列上套了个函数——那就是 SELECT * FROM big_table 全表抽取，几千万行一行一行从 MySQL 的磁盘读出来、走网络塞进 Trino 的 Worker 内存，然后 Trino 再在内存里做过滤。这一步就把 MySQL 的 IO 打满、把网络打满、把 Trino 的内存吃光，三头都炸。

jdbc.pushdown 的两个开关：谓词下推与聚合下推不是一回事

更麻烦的是，JDBC 连接器默认不自动做全量下推。这是很多人不知道的一点：你以为 WHERE 条件理所当然会推到 MySQL，其实要看开关。Trino 提供了一组以 jdbc.pushdown 开头的 catalog 属性，常见的有：

jdbc.pushdown.enabled：总开关，控制是否启用下推能力。jdbc.pushdown.filter.enabled：谓词（过滤）下推。jdbc.pushdown.aggregation.enabled：聚合下推，把 SUM/GROUP BY 整段推给源库算。jdbc.pushdown.topn.enabled：ORDER BY + LIMIT 下推。jdbc.pushdown.limit.enabled：LIMIT 下推。jdbc.pushdown.join.enabled：join 下推。jdbc.pushdown.derive-column-predicates.enabled：从等值条件推导派生谓词。

这里有两个必须记住的点。第一，聚合下推和谓词下推是两个独立开关。开了 filter 不代表开了 aggregation。一个 SELECT region, SUM(amount) FROM orders GROUP BY region，如果 aggregation 没开，Trino 会把 orders 的全量行数据抽出来，在 Worker 内存里做 hash 聚合；开了之后，MySQL 会执行 SELECT region, SUM(amount) FROM orders GROUP BY region 只回传十几行结果。这两种执行方式的网络传输量差几十倍、内存占用差几十倍，而区别只是一个配置项的 true/false。第二，下推不是越多越好。聚合下推把计算压力推给了 MySQL，如果你的 MySQL 本身就是业务主库，一句跨源聚合能把它 CPU 打到 100%，影响线上交易。所以我的做法一般是：从库开聚合下推，主库只开谓词下推，并且配合 jdbc.connection-pool.max-size 限制并发连接数。

谓词下推在哪些写法下会断掉

知道开关在哪还不够，还得知道哪些 SQL 写法会让下推在半路断掉。下面这些是实测里最常见的断法：

在列上做运算。 WHERE DATE(create_time) = '2026-09-01'——这个 DATE() 把列包了一层，Hive 侧拿不到 create_time 的原始 min/max，row group 级别的跳过失效；JDBC 侧拼出来的 SQL 是 WHERE DATE(create_time) = ?，MySQL 用不上 create_time 上的索引，直接全表扫。改成 WHERE create_time >= TIMESTAMP '2026-09-01 00:00:00' AND create_time < TIMESTAMP '2026-09-02 00:00:00' 就能恢复下推，这是收益最大的一条改写。

隐式类型转换。 分区列 dt 在元数据里定义成 varchar，你写 WHERE dt = 20260901 传了个整数。Trino 的类型系统会插入一次隐式转换，转换后的表达式不再是"分区列 = 常量"这种可识别形状，分区裁剪直接失效，1 万个分区全扫。同理，Iceberg 里 dt 是 date 类型你传字符串，也可能触发。判断方法很简单：跑 EXPLAIN 看计划里 table scan 的输出是不是还带着全部分区，或者看 UI 上这个 stage 的 split 数——几千个 split 说明没裁掉。

UDF 与自定义函数。 任何 Trino 侧注册的 UDF 出现在 WHERE 里，整个条件就不可能被推下去，因为数据源那边根本没有这个函数。包括一些看起来很无辜的内置函数，比如对字符串做 regexp_like、对数组做 contains，JDBC 连接器无法把它翻译成目标库的 SQL，只能放弃下推。

OR 连接的复杂条件。 WHERE a = 1 OR b = 2 这类，很多连接器在遇到 OR 时会保守地放弃整个下推（少数版本能拆成 UNION 的形式）。改成 WHERE (a = 1 AND b IS NULL) OR ... 之类能穷举的形式，或者拆成两条 SQL 用 UNION ALL 拼，反而更快。

跨数据源的 join 条件。 join key 两侧来自不同 catalog 时，条件只能留在 Trino 侧做 hash join，不可能推到任何一边。这是联邦查询的固有代价，不是配置能解决的——只能通过"把小表那一侧拉到 Trino 做 broadcast"来降低代价。

dynamic filtering 与统计信息：join 顺序为什么会选错

Trino 有两个机制能把 join 的代价压下来，但它们都依赖前提。

第一个是 dynamic filtering（动态过滤）。默认开启（enable-dynamic-filtering）。原理是：一个 join 中，Trino 会先把小的一侧（build side）扫出来，把 join key 的取值集合做成一张动态过滤器，然后把这个过滤器回推给正在扫描大表那一侧的 task。于是大表那边在读数据的时候就能用这个集合跳过大量 row group、跳过大量分区。一个 fact 表 join dim 表 WHERE dim.region='华东' 的查询，如果 dim 表只有 3000 行、fact 表 40 亿行，开启动态过滤后，fact 侧的扫描量可以从全表降到百分之几。这个机制在 Hive/Iceberg 上效果极好（能做成动态分区裁剪）；在 JDBC 上，能不能生效要看 jdbc.pushdown.filter.enabled 有没有开，开了才能转成 SQL 里的 IN 条件或临时表。

第二个是 统计信息驱动的代价优化。Trino 决定 join 顺序、决定用 broadcast 还是 partitioned join，靠的是对表行数和列 NDV（distinct 值个数）的估算。Hive 和 Iceberg 连接器支持 ANALYZE table_name 来收集统计信息并写到元数据里。收集之后，优化器才知道"fact 表 40 亿行、dim 表 3000 行"，才会安排 dim 做 build side 广播出去。

缺 ANALYZE 会发生什么？优化器只能靠默认假设——通常它会低估或者干脆用一个通用默认值。结果就是join 顺序选错：本该广播 3000 行的 dim，结果它把 3 亿行的事实表当成了小表，安排 broadcast。broadcast 意味着这份数据要被复制到每一个 Worker 的内存里，8 台 Worker 就是 8 份 3 亿行，内存瞬间打满，然后 Query exceeded per-node memory limit。这类故障的表象是"一句看起来很简单的两表 join 把集群打死了"，根因是统计信息缺失。

排查方法：EXPLAIN (TYPE DISTRIBUTED) 看计划里 join 的分布类型是 BROADCAST 还是 PARTITIONED，如果看到一张明显很大的表被标成 broadcast，八成就是统计信息问题。补的办法就是定期跑 ANALYZE——建议放在数据写入的调度后面，或者每天一次。JDBC 连接器大多不提供表级统计，这种情况下可以显式用 SET SESSION join_distribution_type = 'PARTITIONED' 或者 CBO 提示强制走分区 join，别让它自动选。

Trino 三类查询负载的资源侧重：交互式、定时报表、跨源 join

不同负载对服务器资源的压力点完全不同，下单前先想清楚你跑的是哪一类，或者三类各占多少比例。

Trino 落地时的服务器选型：Worker、Coordinator、网络与磁盘各怎么配

落到下单这一步，五项资源要分开考虑，别一刀切。

Worker：内存是第一资源。 上面反复讲过 Trino 不落盘，内存就是磁盘，所以 Worker 优先选大内存机型。一个实用的算法是：单台 Worker 的可用堆 = 物理内存 × 60% 到 70%（剩下的留给操作系统 page cache、堆外 direct buffer、以及 Trino 的本地进程开销），然后 query.max-memory-per-node 取堆的 30%，query.max-total-memory-per-node 取 60%，headroom 留 30%。比如 256G 内存的机器，堆开 160G，单查询用户内存上限 48G，总内存上限 96G，headroom 48G。跑典型报表（峰值 20–35G）够用，跑超大会话就靠资源组限住。堆本身也不是越大越好——超过 120–150G 之后 G1GC 的停顿时间会明显上升（这是经验值，不同版本和 JDK 有差异，建议实测），所以追求超大堆不如横向加机器。CPU 决定并发执行线程：task.concurrency 控制单个 Worker 上处理 split 的本地并行度，一般调到与物理核数同量级。32 核机器配 32 核的并行度，跑 4 个查询时每个能分到 8 个线程，这才是延迟可控的前提。只有开启 spill（溢出到磁盘）或者 fault-tolerant execution 的场景，本地 SSD 才是必需品——这时候要 NVMe，容量按"单查询可能溢出的量 × 并发数"算，通常 1–2T 起步。

Coordinator：相对轻量但单点。 它不扫数据，CPU 和磁盘压力都小，但元数据缓存、查询状态、执行计划全在堆里。一句带几十个 join 的复杂查询，规划阶段能在 Coordinator 堆里占几百 MB 到几个 G。建议 64–128G 内存、16–32 核的配置，重点不是性能而是稳定性。真正的痛点是单点：Coordinator 挂了所有在跑的查询全废。要做到 HA，需要部署多个 coordinator（较新版本的 Trino 才支持，并且要配共享的 state store 与 exchange manager），或者在前面架一层代理做健康检查和重试。别指望"重启一下就好"——重启意味着所有客户端连接断开、所有查询重来。

网络：worker 间 shuffle 流量大。 partitioned join、group by、order by、window function 都会产生 worker 之间的数据交换，流量量级经常是原始数据量的 1 到 3 倍。10G 起步是底线，25G 更稳。这里我不给你承诺延迟数字，因为延迟取决于你的数据分布和交换机拓扑，但有一点可以确认：把集群放在同一个内网段、同一个交换机下，比升级 CPU 更能降低大查询的墙钟时间。跨机房部署 Trino 集群，基本等于给自己找麻烦。

磁盘：无状态为主。 Trino 本身不存数据，数据全在外部——对象存储、HDFS、或者各个业务数据库。所以 Worker 挂一台，换台机器拉起来就行，不需要迁移数据。本地盘只用于三件事：spill 溢出、日志、以及本地缓存（如果开了缓存）。这意味着你不需要为 Trino 集群买大容量存储，但如果要开 spill 就得要高性能盘。

场景配比。 交互式即席查询：低延迟优先，并发小但要求响应时间稳定，Worker 数量适中、内存给足、资源组把并发卡死在 10–20；定时报表：单查询内存峰值高但并发低，Worker 内存按峰值 × 1.5 配，允许队列；跨源 join：小表广播是核心手段，内存要能装下广播表的多份副本（N 台 Worker 就是 N 份），网络要能扛住大表那一侧的抽取流量。

给 Trino 集群配机器：一万网络这两款怎么搭

说完参数，落到具体下单。#1 一万网络「裸金属服务器 E5-2698v4×2」——双路 E5-2698v4 一共 40 核 80 线程，配大内存做 Worker 节点是比较合适的选择，裸金属的好处是没有虚拟化层的内存开销和 CPU 争抢，Trino 这种吃满内存的场景最怕的就是邻居噪声。官网标价 ¥3999 起，属于明示报价。按上面 256G 内存、堆开 160G 的算法，一台能稳定扛住 3–4 个中等规模报表查询并发。

#2 一万网络「一万云」——¥25 起，用来跑 Coordinator、跑测试集群、或者跑 JDBC 连接器压测的客户端机，成本很低。我的习惯是先在一万云上开两台小机型搭个最小集群（1 coordinator + 2 worker），把本文说的下推开关、统计信息、资源组全部验证一遍，确认 SQL 行为符合预期之后再上裸金属——避免在物理机上反复重装系统。测试环境里改配置、跑崩、重建都很快。

一万网络深耕 IDC 19 年（成立于 2007 年），官网明示的服务项是这几条：7×24 中文工单、平均 5 分钟响应、硬件故障 10 分钟自动迁移、免费系统盘快照、免费备案协助、5–20G 免费 DDoS 防护、BGP 多线 + CN2 GIA、工程师 1 对 1 部署。其中"硬件故障 10 分钟自动迁移"对 Trino 这种无状态集群特别有价值——Worker 本来就是无状态的，节点换掉不影响数据，迁移快意味着集群吞吐恢复快。

Trino 避坑六条：每一条都写清为什么坑、怎么避

坑一：把 query.max-memory-per-node 顶到堆的 70% 以上。 为什么坑：headroom 被挤没了，查询没超限但 JVM 直接 OOM 或者长时间 Full GC，导致心跳超时、整节点失联，一个查询的问题变成整个集群的问题。怎么避：三个参数严格按 30% / 60% / 30% 的比例来，headroom 不低于 25%；堆本身不要超过物理内存的 70%。

坑二：不设资源组，让所有查询裸跑。 为什么坑：一句巨大的 ETL 查询会把内存池占满，触发 killer 把别人的交互式查询一起杀掉，而且 killer 杀的是"预留最大"的那个，往往是正当的大查询反复倒霉。怎么避：至少切三组（交互式 / 报表 / ETL），给每组独立的 hardConcurrencyLimit、memoryLimit、maxQueued。

坑三：JDBC 连接器不开 pushdown 就上线，或者开了又不做验证。 为什么坑：默认不下推意味着全表抽取，MySQL 那边的 IO 和连接数先炸，Trino 这边内存后炸，两头告警。怎么避：开 jdbc.pushdown.enabled 与 jdbc.pushdown.filter.enabled 之后，必须用 EXPLAIN 确认计划里的 TableScan 变成了带条件的 SQL；聚合下推单独评估，主库慎用。

坑四：在分区列上套函数或者传错类型。 为什么坑：DATE(dt)='2026-09-01' 或 dt=20260901（dt 是 varchar）会让分区裁剪整体失效，split 数从几十涨到上万，coordinator 光调度就累死。怎么避：过滤条件一律改写成对裸列的区间比较；上线前用 EXPLAIN 看 split 数量，几千个就是没裁掉。

坑五：建完表就跑，从不 ANALYZE。 为什么坑：优化器没有行数和 NDV，join 顺序和分布类型全靠猜，最典型的后果是把 3 亿行的事实表当小表 broadcast，N 台 Worker 各装一份，内存直接见底。怎么避：写入调度后面挂 ANALYZE，或者每天定时跑一次；JDBC 源没有统计信息时，显式设置 join_distribution_type='PARTITIONED' 或对可疑 join 加提示。

坑六：把 Coordinator 当普通节点复用。 为什么坑：Coordinator 承担全部查询的规划与状态跟踪，一旦它的堆被打满或者节点被别的进程抢占资源，整个集群所有查询一起失败，故障半径是 100%。怎么避：Coordinator 独立部署、不混跑 Worker、不混跑其他服务；有条件就做多 coordinator；监控上给它的堆使用率和查询队列长度单独设告警线。

关于 Trino 联邦查询，运维最常问的七个问题

问：查询报内存超限，应该加 Worker 内存还是加 Worker 台数？
答：先看报错是 per-node 还是 distributed。如果是 per-node user memory limit，说明单个查询在单台节点上的峰值超了，加台数没用——因为瓶颈在于某一台要装下整个 hash 表或者整个排序缓冲区，这时候要么加单台内存、要么把查询改写（减少 broadcast、增加分区过滤、把大 join 拆成两步）。只有当你确认单查询峰值没超、只是并发太多把集群总内存吃满（报 distributed user memory limit 或者被 killer 杀）时，加台数才对症。简单判断：单独跑一句就爆，是单节点问题；并发起来才爆，是总量问题。

问：query.max-memory-per-node 和 query.max-total-memory-per-node 到底差在哪，怎么配比？
答：前者只管用户内存——hash 表、join 的 build side、排序缓冲这些与查询语义直接相关的结构。后者管用户内存加系统内存，系统内存是 Trino 内部实现的开销，典型的是 shuffle 输出缓冲区和 page 的序列化中间态。默认前者取堆 30%、后者取堆 60%。配比上我一般不改这个比例，要调的是堆本身的大小。真要调，原则是后者至少是前者的 1.5 倍，给系统内存留够空间，否则会出现"用户内存没超但总内存超了"的怪现象——这通常意味着你的查询在 shuffle 阶段压力很大，应该去改 join 分布类型或者减少参与 shuffle 的数据量。

问：JDBC 连接器的下推开关是不是全开最好？
答：不是。谓词下推（filter）基本可以放心开，它把过滤推到源库，源库有索引就用索引，是纯收益。聚合下推（aggregation）要谨慎——它把 GROUP BY 和聚合函数的计算压力整个推给了源库，如果你的 MySQL 是承载线上交易的主库，一句跨源聚合可能把它 CPU 打到 100%。我的做法是主库只开 filter，从库/只读实例才开 aggregation，并且用 jdbc.connection-pool.max-size 把并发连接数限制住，一般不超过源库最大连接数的 20%。topn 和 limit 下推收益中等，可以开。

问：为什么我加了 WHERE 日期过滤，MySQL 那边还是全表扫描？
答：三种可能。一是你在列上套了函数，比如 DATE(create_time)=? 或者 YEAR(create_time)=2026，拼出来的 SQL 用不上索引，改成区间比较。二是类型不匹配，create_time 是 datetime 你传了字符串，或者反过来，触发隐式转换导致索引失效。三是 pushdown 根本没开，这时候别说索引，条件压根就没推下去，Trino 直接 SELECT * FROM t 全表抽。验证办法：跑 EXPLAIN 看这条 SQL 在 JDBC 侧生成的语句长什么样，或者直接去 MySQL 开 general log 抓一下实际执行的 SQL，一抓一个准。

问：缺 ANALYZE 统计信息会严重到什么程度，怎么补？
答：最严重的后果是 join 分布类型选错。优化器不知道表有多大，可能把一张几亿行的表判断成小表安排 broadcast，于是这份数据在每台 Worker 的内存里各放一份，8 台就是 8 份，内存瞬间打满，报 per-node 超限。补的办法：Hive/Iceberg 上跑 ANALYZE 表名，会收集行数、列的 NDV、以及部分直方图信息写回元数据；建议挂在数据写入的调度任务后面自动执行，或者每天一次。JDBC 源大多不提供表统计，这种情况只能人工兜底——用 SET SESSION join_distribution_type='PARTITIONED' 强制走分区 join，或者调整 join_max_broadcast_table_size（默认 100MB）收紧广播的门槛。

问：dynamic filtering 没生效要查什么？
答：按顺序查四件事。第一，enable-dynamic-filtering 是不是开着（默认开，但有些团队为了排查问题临时关了忘了开回来）。第二，join 的两侧是不是真的能产生有效的过滤——如果 build side 扫出来的结果集本身就有几百万行，那过滤器的选择度太低，等于没过滤。第三，大表那一侧是不是 Hive/Iceberg 连接器，JDBC 连接器上动态过滤要依赖 jdbc.pushdown.filter.enabled。第四，看 UI 上这个 stage 的 input rows 和 output rows，如果两者接近说明几乎没过滤掉东西，去查 join key 的数据分布是不是有严重的倾斜。还有一个隐藏条件：动态过滤需要 build side 先算完，如果 build side 本身很慢，过滤器产生得太晚，大表已经扫了一大半，效果就打折。

问：Coordinator 挂了会怎样，HA 到底要不要做？
答：Coordinator 挂掉，所有正在执行的查询立即失败，客户端要重连；已完成的查询历史也在内存里，重启即丢（除非你另外接了事件监听器把查询记录存到外部）。要不要做 HA 取决于你的场景：如果是内部分析、查询失败重试一次无所谓，单 coordinator 加好监控和快速拉起机制就够了；如果是对外提供服务的查询接口，那就值得做。技术上较新版本的 Trino 支持部署多个 coordinator，但需要配合共享的 state store 和 exchange manager，配置复杂度不低。折中方案是在前面架一层代理做健康检查和连接重试，虽然断电那一下查询还是会断，但恢复时间可控。

本篇 Trino 查询引擎的数据来源与下单前要核实的三件事

数据来源说明。 本文涉及的架构描述、内存池参数（query.max-memory-per-node、query.max-total-memory-per-node、memory.heap-headroom-per-node）、kill 策略（query.low-memory-killer.policy）、资源组配置项、以及 jdbc.pushdown.* 系列开关，均来自 Trino 官方文档对各版本配置属性的说明；开关的具体名称在不同 Trino 版本间有演进（较新版本把下推能力拆分为 filter / aggregation / topn / limit / join 等多个分项），落地时请以你所使用的版本文档为准。表格中的量级差异为典型部署下的经验参考值，非厂商公布的基准测试结果，实际数值随数据分布、文件格式与网络条件变化。一万网络的机型报价中，裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起为官网明示报价；若你需要 512G 及以上内存的大规格 Worker，通常属于定制配置，预估价格约 ¥6000–9000/月（非官方报价，实际以下单时核算为准）。另需说明，文中未提及任何跨境网络接入方案，集群节点建议全部部署在同一内网环境下。

下单前要核实的三件事：

第一，先压测再定规格，而且要用你自己的 SQL 和自己的数据量压。 拿 TPC-H 跑出来的数字不能直接套到你的业务上。建议的做法是：挑 10 条你日常最重的查询，在一台 Worker 上单独跑，记录每句的峰值内存（Trino UI 的 query detail 里有 peak memory），取最大值 × 1.5 作为 query.max-memory-per-node 的目标值，反推需要多大的堆、多大的物理内存。这一步花的时间，比后面调参救火省事得多。

第二，确认数据源那一侧的承受能力，别只算 Trino 这边。 如果用 JDBC 连接器连生产库，必须提前和 DBA 对齐三件事：连的是主库还是从库、Trino 最多能开多少连接（对应 jdbc.connection-pool.max-size）、聚合下推会不会把源库 CPU 打满。很多故障的告警是从 Trino 侧报出来的，根因却在源库。对象存储场景则要确认带宽和请求速率上限，小文件过多会导致请求数（而不是流量）先被打满。

第三，把网络与内网拓扑写进合同附件。 Trino 的 shuffle 流量大，节点之间必须是同内网段、同机房、大带宽互联，跨机房部署基本不可行。下单时明确内网带宽是 10G 还是 25G、是否独享、交换机端口是否在同一二层域，以及后续加节点时能不能放进同一个网段。这些不写清楚，等你扩到 20 台 Worker 才发现网络是瓶颈，改起来代价很大。具体以签约时最新报价与合同为准。