内置数据源和外部数据库混用时，查询下推和内存计算边界在哪？

一、问题的定义：混用场景为何天然存在代价断层

1.1 什么是“混用”，以及它与联邦查询的区别

本文所说的混用（mixed-source execution），指同一条查询计划中同时包含内置数据源算子与外部数据库算子，且二者之间存在数据依赖（连接、半连接、聚合后再过滤等）。它与传统联邦查询（federated query）的关键区别在于：联邦查询通常以“包装器 + 统一元数据”为核心，重点解决模式异构与访问统一；而混用场景的核心矛盾是执行位置的选择——同一段逻辑算子，究竟在远端数据库执行，还是把数据拉回本地由内置引擎执行。

这个区别决定了优化目标不同。联邦查询追求“能查到、查得对”；混用场景追求“查得快且不失控”。后者的难点不在语法层，而在代价层：本地优化器的统计信息、硬件假设、并行度模型，与远端数据库的完全不同。本文评述：把下推简单理解为“把 SQL 片段拼到远端”，是工程上最常见的认知偏差；真正需要判断的是远端能否以可验证的方式承接这段算子的语义与代价。

1.2 代价断层的四个来源

混用场景的代价断层并非单一因素造成。笔者将其归纳为四类，且这四类会相互放大：

这四类来源中，前两类属于可量化但难校准，后两类属于可规避但易被忽略。笔者认为，工程实践中最危险的不是“估计不准”，而是“估计不准却没有任何校验机制”。因此后文会把“可验证性”作为决策模型的一等公民，而不是事后调优的补丁。

1.3 一个最小可复现的对照场景

为便于讨论，构造一个典型混用查询：内置表 orders_local（约 2000 万行）与外部库表 customers_ext（约 300 万行）按 cust_id 连接，过滤条件分别落在两端。以下为示意 SQL，非特定产品语法：

SELECT o.cust_id, SUM(o.amount) AS gmv
FROM   orders_local o
JOIN   customers_ext c ON o.cust_id = c.cust_id
WHERE  o.dt BETWEEN '2025-01-01' AND '2025-03-31'
  AND  c.region = 'EAST'
  AND  c.level  >= 3
GROUP  BY o.cust_id
HAVING SUM(o.amount) > 10000;

这条查询至少有四种执行位置组合：（a）全部拉回本地计算；（b）把 c 的过滤下推远端、连接在本地；（c）把连接整体下推远端（需远端能访问 orders_local，通常不可行）；（d）两端各自预聚合后再连接。哪一种更优，取决于选择率、连接基数与传输成本，而不是固定规则。这个例子将贯穿后文的决策模型。

1.4 拓展阅读

关于查询下推与联邦执行的基础概念，可参考 PostgreSQL 官方文档中外表与下推相关章节（postgresql.org/docs），以及 Apache Calcite 关于规则优化与下推的文档（calcite.apache.org）。视频类资料可参考 CMU 15-721 数据库系统课程中关于执行与优化的公开课（15721.courses.cs.cmu.edu）。

二、下推能力的分层矩阵：从谓词到窗口函数

2.1 为什么必须分层，而不是二分

“能下推 / 不能下推”的二分法在工程上几乎没有指导意义，因为下推是一个语义保持强度递减、收益不确定性递增的谱系。谓词下推几乎总是安全的（在排序规则与类型一致的前提下），而窗口函数下推则高度依赖远端实现。笔者主张按算子类别建立分层矩阵，每一层给出“可下推条件、验证方法、回退策略”三要素。

2.2 分层能力矩阵

本文评述：这张矩阵的价值不在“查表”，而在提醒工程师——下推层级越高，验证成本越高，回退路径越必须显式设计。L1–L2 可以默认开启并辅以结果校验；L3–L4 需要统计信息支撑；L5–L6 应当默认关闭，仅在明确收益且经过回归验证后开启。

2.3 语义等价性：最容易被低估的边界

语义等价性缺口往往不体现在“报错”，而体现在“结果差一点”。常见来源包括：字符串排序规则（collation）在两端不同，导致 ORDER BY 与范围谓词结果不一致；DECIMAL 与 DOUBLE 的舍入差异；时区与 TIMESTAMP 语义差异；以及 NULL 在聚合与比较中的处理差异。

笔者认为，语义等价性应当被当作契约来管理，而不是当作“已知问题”来容忍。可行的做法是为每个外部数据源维护一份“语义能力声明”，记录排序规则、数值类型映射、时区策略与 NULL 语义，并在下推决策时作为硬约束参与判断。这份声明可以由连接器配置生成，也可以通过自动化探测脚本定期校验。

2.4 一个可操作的语义探测脚本思路

下面给出一个与具体产品无关的探测思路，用于在接入新外部库时快速识别语义缺口。核心是构造“边界值小表”，在两端执行同一逻辑并比对结果：

-- 探测项 1：排序规则与大小写
SELECT 'a' < 'B' AS cmp_result;          -- 两端比对

-- 探测项 2：NULL 在聚合中的行为
SELECT COUNT(*), COUNT(v), SUM(v) FROM probe_nulls;

-- 探测项 3：数值舍入
SELECT CAST(1.005 AS DECIMAL(10,2)) AS rounded;

-- 探测项 4：时区语义
SELECT CURRENT_TIMESTAMP AT TIME ZONE 'UTC';

将上述结果写入一张“语义指纹表”，作为下推白名单的依据。这个做法成本很低，但能拦截绝大多数“结果差一点”的线上问题。本文评述：与其在事故后排查，不如在接入时把语义差异显式化；这也是把隐性知识转化为可执行工程资产的过程。

三、边界判定：三维决策模型与操作路径

3.1 决策模型：可下推性 × 收益比 × 风险度

笔者提出一个三维决策模型，用于把“边界在哪”转化为可执行的判断流程。三个维度分别是：可下推性 P（语义与能力是否支持）、收益比 B（下推后减少的传输/计算量相对新增开销的比值）、风险度 R（结果偏差概率与回退成本）。决策规则不是简单加权，而是分层过滤：

1. 硬约束过滤：若 P 不成立（语义不等价或能力缺失），直接回退本地内存计算，不进入收益评估。
2. 收益门槛：若 B 低于阈值（例如下推后传输量减少不足 30%，且远端往返开销显著），回退本地。
3. 风险兜底：若 R 偏高（如涉及浮点聚合、复杂排序），即使 B 较高，也应采用“下推 + 结果校验”或“影子执行”策略。

这个模型的工程价值在于：它把“经验判断”拆成了三个可观测的量。P 可以由语义指纹表给出；B 可以由统计信息与代价模型估算；R 可以由历史回归结果与算子类型给出。三者都不完美，但组合起来足以形成稳定的决策基线。

3.2 收益比的估算方法

收益比的核心是估算“下推前后数据流动量”的差值。设远端表过滤后行数为 N_remote，本地表过滤后行数为 N_local，连接选择率为 s，行宽为 w。若把远端过滤与预聚合下推，传输量从 N_remote × w 降为 G × w'（G 为分组数）。当 G × w' ≪ N_remote × w 时，下推收益显著。

但要注意一个反直觉现象：预聚合下推并不总是更快。如果远端数据库的聚合算子未向量化，或分组键基数极高导致哈希表膨胀，远端聚合可能比本地向量化聚合更慢。本文评述：收益比必须同时考虑“传输节省”和“远端算子效率”，只看前者会得出错误结论。可行的做法是在基准环境中对典型查询做 A/B 对照，把结果沉淀为规则。

3.3 操作路径：从查询到决策的六步法

把模型落到工程，需要一条可重复执行的路径。笔者总结为六步：

1. 算子切分：把逻辑计划按数据源边界切分为若干子树，标记跨源边。
2. 能力匹配：对每个子树查询语义指纹表，确定 P 值。
3. 基数估算：分别用本地与远端统计估算过滤后行数，取保守值。
4. 收益计算：按 3.2 的方法估算 B 值，与阈值比较。
5. 风险标注：按算子类型与历史回归结果给出 R 值，决定是否需要校验。
6. 计划固化：把决策结果写入查询提示（hint）或规则配置，避免每次优化器随机选择。

第六步常被忽略，但它决定了系统行为的可预测性。优化器的代价模型在混用场景下本就不稳定，若不固化，同一查询在不同时间可能得到不同计划，给容量规划与故障排查带来困难。笔者认为，可预测性本身就是一种性能。

3.4 边界判定的反例：何时应当主动放弃下推

有三类场景，即使下推在技术上可行，也应主动放弃：其一，远端是共享型数据库且存在并发限流，下推会放大对远端的压力，影响其他业务；其二，查询涉及敏感字段，下推意味着把过滤逻辑与字段暴露给远端，需评估合规边界；其三，远端版本升级频繁，下推依赖的函数语义可能变化，维护成本高于收益。

本文评述：这三类反例说明，边界判定不只是性能问题，还涉及资源治理与合规。把下推决策纳入统一的查询治理框架，比在优化器里做局部最优更有价值。

四、工程验证：执行计划审计与回归基准

4.1 执行计划审计：看什么、怎么看

执行计划审计的目标不是“确认下推发生了”，而是“确认下推的代价假设成立”。审计应关注四类信息：跨源边的数据量估算与实际行数、远端执行的算子列表、连接建立与序列化耗时、以及是否存在隐式类型转换。多数引擎的 EXPLAIN 输出会标注下推片段，但估算行数与实际行数的偏差需要运行时统计才能获得。

一个实用的审计方法是“双跑对照”：同一查询分别在“强制下推”和“强制本地”两种模式下执行，记录实际行数、耗时与峰值内存。若两者结果集一致而耗时差异显著，说明下推决策有效；若结果集不一致，则说明存在语义缺口，应立即回退并修复语义指纹表。

4.2 回归基准的构建

回归基准应覆盖三类查询：点查与窄范围扫描（验证 L1–L2）、聚合与 TopN（验证 L3–L4）、跨源连接与窗口（验证 L5–L6）。每类查询准备固定数据集与预期结果，在每次连接器升级或引擎版本变更后自动执行。基准数据可以是模拟数据，但必须标注生成规则与规模，避免把模拟结果当作生产结论。

本文评述：回归基准的难点不在搭建，而在维护。建议把基准查询与语义指纹表放在同一仓库，版本化管理，并在 CI 中作为门禁。这样“边界”就不再是文档里的一句话，而是可执行的约束。

4.3 拓展阅读

关于执行计划分析与基准测试方法，可参考 Apache Calcite 的规则调试文档（calcite.apache.org/docs/adapter）以及 Trino 关于连接器下推的官方说明（trino.io/docs）。视频资料可参考 Apache Calcite 社区分享的优化器实践（YouTube 检索）。

五、边界漂移：向量化、湖仓格式与分布式执行

5.1 向量化引擎如何改变收益比

过去十年，主流分析引擎普遍采用向量化执行与列式内存布局，本地聚合与连接的吞吐显著提升。这带来一个直接后果：本地内存计算的相对成本下降，下推的收益门槛相应提高。当本地引擎能以每秒数亿行的速度处理过滤与聚合时，把中等规模数据拉回本地往往比在远端执行更可控。

本文评述：这意味着“下推优先”的默认策略需要重新审视。更合理的默认是“小结果集下推、大结果集本地”，并以传输量而非算子位置作为主要判据。向量化引擎的普及，实质上把边界从“远端能力”一侧推向了“传输成本”一侧。

5.2 湖仓表格式与统计信息下推

开放表格式（如 Iceberg、Delta Lake、Hudi）在元数据中维护了分区统计、列级 min/max 与文件级摘要，使得谓词下推可以在文件裁剪层面生效。这类“元数据下推”不依赖远端数据库的计算能力，而是依赖格式规范与读取器的实现质量。其边界在于：统计信息的粒度与新鲜度决定了裁剪效果，过期统计会导致无效读取。

笔者认为，湖仓格式带来的最大变化是下推决策从“运行时”前移到“元数据层”。工程师可以通过检查表的元数据健康度（统计覆盖率、文件大小分布、分区粒度）来预判下推效果，而不必等到执行时才暴露问题。这为容量规划提供了更早的信号。

5.3 分布式执行与数据倾斜

在分布式执行框架中，跨源连接往往通过广播或重分区实现。若连接键分布倾斜，本地内存计算可能因单个分区过大而溢出，此时下推到远端反而可能更稳。但远端同样可能因倾斜而变慢，因此倾斜场景的边界判定需要额外的运行时自适应机制，例如动态切换连接算法或拆分热点键。

本文评述：倾斜是“边界漂移”的典型例子——它不改变语义，却改变代价。任何静态决策模型都无法完全覆盖倾斜，因此工程上应保留“运行时重优化”的通道，并为其设置明确的触发条件与回退上限。

5.4 前沿方向与学术预判

近三年的研究热点集中在“学习型代价模型”与“跨系统自适应执行”。前者试图用机器学习替代手工代价公式，缓解统计信息不可比的问题；后者强调在执行过程中根据实际基数动态调整算子位置。两类方向的共同前提是可观测性——没有细粒度的运行时指标，任何自适应都无从谈起。

笔者认为，短期内更现实的路径不是追求“全自动边界”，而是建立“可解释的半自动决策”：由模型给出建议，由规则与基准提供约束，由人工在关键查询上确认。这种模式在工程上更稳健，也更容易积累组织内的知识资产。

六、总结与展望

回到最初的问题：内置数据源与外部数据库混用时，查询下推与内存计算的边界在哪？本文给出的答案是——边界不在某个固定算子，而在代价模型的可迁移性。当远端能以可验证的方式承接语义与代价时，下推成立；当语义出现缺口、收益被开销吞噬、或风险不可控时，边界回收到本地内存计算。

工程上，这条主线可以落成三件可执行的事：维护语义指纹表，把隐性差异显式化；用三维决策模型替代经验判断，把边界判定流程化；以回归基准与执行计划审计形成闭环，把决策固化为可预测的行为。三者结合，才能在混用场景中既获得下推的收益，又避免其风险。

展望未来，向量化引擎会继续压低本地计算成本，湖仓格式会把下推前移到元数据层，学习型代价模型会尝试缓解统计不可比。但无论技术如何演进，“可验证性”都将是边界判定的基石。笔者相信，真正成熟的混用系统，不是下推最多的系统，而是对自身边界最清楚的系统。