SQL 联邦查询（federated query）的 Athena / Presto / Trino vs 原生 FDW 性能对比

athena/trino联邦查询比postgresql fdw慢，因前者默认全量拉取远程数据再过滤，后者支持谓词、join、group by等下推；性能差异由架构决定，非配置问题。

为什么 Athena/Trino 的联邦查询比 PostgreSQL FDW 慢得多

因为底层数据拉取方式完全不同：FDW 是按需下推谓词、字段、LIMIT，而 Athena/Trino 默认把整张远程表（或大分区）全量拉到计算层再过滤。不是配置问题，是架构决定的。

• Presto/Trino 的 mysql 或 postgresql connector 默认不自动下推 WHERE 条件，除非目标库支持且 connector 显式启用（如 mysql.case-insensitive-name-matching=true 不影响下推）
• Athena 的 mysql / postgres 连接器（通过 Athena Query Federation SDK 构建）默认只下推简单等值条件，IN、范围查询、函数表达式基本不走下推
• PostgreSQL FDW（如 postgres_fdw）在 10+ 版本后支持较完整的下推：包括 JOIN、GROUP BY、大部分 WHERE 子句，只要远程库能执行，本地就尽量不下发原始扫描

怎么让 Trino/Athena 实际用上谓词下推

不能靠“开启某个开关”一劳永逸，得逐连接器确认能力边界，并手动约束 SQL 写法。

• 查 system.metadata.table_comments 看 connector 是否标记了 supports-predicate-pushdown=true（Trino），但该字段只是声明，不保证生效
• Trino 中对 MySQL 表做 EXPLAIN (TYPE DISTRIBUTED)，看 ScanFilterProjectNode 下是否有 RemoteExchange —— 如果有，说明过滤没下推；如果只有 TableScanNode 且含 filter 字段，才算真正下推
• Athena 要检查 QueryExecutionStatistics.DataScannedInBytes：同样一条 SELECT * FROM remote_table WHERE id = 123，如果扫了 GB 级数据，基本可断定没下推；正常应只扫 KB 级
• 避免在 WHERE 里写 UPPER(name) = 'ABC' 或 date_trunc('day', ts) = current_date —— 这类表达式几乎必然导致全表拉取

FDW 在什么场景下反而更慢甚至失败

不是所有情况 FDW 都赢。当远程表极宽（上百列）、单行极大（JSON/BLOB 占比高），或网络延迟高但带宽足时，FDW 的同步阻塞模型会卡死整个查询计划。

阿里云AI平台

阿里云AI平台

下载

• postgres_fdw 默认使用同步查询协议，一次只能发一个请求，无法并发拉多个分区 —— 对跨月分区的 sales_2024_01…sales_2024_12，它会串行连 12 次数据库
• 远程库若无索引，FDW 下推的 WHERE 仍要全表扫，但此时数据已从远端流式传回本地，网络 + 序列化开销叠加，比 Trino 在远端内存中扫完再传结果更重
• FDW 不支持远程 LIMIT/OFFSET 下推到分页查询（如 LIMIT 10 OFFSET 1000），会把全部匹配行拉回来再截断，OOM 风险高

别忽略连接池和超时配置的实际影响

性能差异里，至少 30% 出自连接管理 —— 尤其在高并发小查询场景下。

• Trino 的 mysql connector 默认每节点最多 5 个连接，max-connection-lifetime=30m；而 postgres_fdw 的 postgres_fdw.max_connections（9.6+）默认为 0（不限），但实际受限于远程库 max_connections 和本地 shared_buffers
• Athena federation 的 Lambda 执行时间上限是 15 分钟，一旦远程查询超时，整个联邦查询直接失败，不会重试或降级；FDW 则抛出 ERROR: connection to server was lost，至少能捕获重试
• 所有方案都怕 DNS 波动 —— Trino/Athena 通常复用连接，DNS 失效后新连接建不起来；FDW 每次查询都可能新建连接，更容易暴露解析失败，但日志里只显示 could not connect to server，看不出是 DNS 还是 auth 问题

复杂点在于：没有通用“最优方案”，只有“当前 schema + 查询模式 + 基础设施 SLA”下的相对合理选择。比如你查的是日志表、每天新增 2TB、只按时间范围过滤 —— FDW 的分区剪枝能力可能碾压 Trino；但如果你要关联 5 个不同云厂商的 MySQL 实例做实时报表，FDW 的运维成本和单点故障风险就远高于 Trino 的 connector 模型。