Connector 与 Pushdown：把 Flux 查询下推到 SQLite/MySQL

Sat, 23 May 2026 00:00:00 +0000

前面几篇文章已经把 Flux 的词法语法、类型值模型、执行器和表流管线串起来了。到这里，查询引擎终于要碰到一个更现实的问题：数据不一定在内存里，也不一定来自小 CSV，它可能在 SQLite 文件中，也可能在远端 MySQL 实例里。

如果还沿用最朴素的解释器思路，sqlite.from() 先把整张表读成 TableValue，再让 range、filter、keep、sort 在内存里慢慢跑，那么这个实现虽然容易写，却很难称为查询引擎。真正有意义的边界是：Flux 仍然是统一查询语言，但能够把安全、明确、可证明等价的一段计划下推到数据源附近执行。

这一篇就专门讲 cpp/pl/flux 当前的 connector 与 pushdown 设计。它不是“把 Flux 翻译成任意 SQL”，而是一套更保守的执行模型：provider package 负责建立数据源入口，optimizer 识别可下推前缀，connector runtime 按 metadata、split、page source 三层执行，unsupported suffix 则可靠 fallback 回内存执行器。

先看一条典型查询：

import "sqlite"

sqlite.from(path: "metrics.db", table: "cpu")
    |> range(start: 2024-01-01T00:00:00Z, stop: 2024-01-01T01:00:00Z)
    |> filter(fn: (r) => r.host == "edge-1" and r._value > 80.0)
    |> keep(columns: ["_time", "host", "_value"])
    |> sort(columns: ["_time"])
    |> limit(n: 10)

从用户视角看，这就是一条普通 Flux pipeline。从引擎内部看，它可以被拆成两段：前缀部分能变成 SQL SELECT ... WHERE ... ORDER BY ... LIMIT ...，后缀部分如果还有复杂 Flux 算子，则继续由内存 runtime 接管。这个“能不能下推”的判断，就是本文的核心。

Mysql - 标签 - 星河拾贝录

Connector 与 Pushdown：把 Flux 查询下推到 SQLite/MySQL