在工厂信息化建设里最常被吐槽的一句话往往是“数据都有但查不出来”。生产订单在 MES 里质量检验在 QMS 里原材料入库在 WMS 里设备参数又落在 SCADA 或时序库里系统之间数据格式不同、数据库不同甚至服务器也不同。质量人员想按工单把检验结果、生产批次、设备参数放在一起看要么等数据团队导数据要么自己导 Excel 再 VLOOKUP过程慢也容易出错。联邦查询Federated Query就是解决这类问题的思路不用先把数据搬到一起而是让同一个 SQL 引擎直接连接多个数据源把“跨库跨表查询”变成一条 SQL 就能完成的事情。本文面向制造企业的数据分析师、数据开发工程师和信息化负责人会用最小实验把 MySQL 里的质量检验表和 PostgreSQL 里的生产工单表做跨库关联再讲清楚查询下推、结果合并、权限控制以及生产落地时需要注意的问题。1. 工厂数据查询难难在数据根本不在一个库1.1 一个典型的工厂数据分布案例制造企业往往不是缺系统而是系统太多。每个业务部门都有自己习惯的软件和数据库MES 记录工单和报工QMS 记录质量检验和缺陷WMS 管理原材料和成品出入库SCADA 或工业时序库保存设备点位数据ERP 保存物料、BOM 和订单。下面是一张很常见的工厂数据分布表业务系统常见数据库典型数据数据特征MES 制造执行系统PostgreSQL、SQL Server工单、工艺路线、报工记录结构化写入频繁QMS 质量管理系统MySQL、Oracle检验记录、缺陷代码、不合格品高频插入按时间查询WMS 仓储系统SQL Server、MySQL出入库记录、库存快照实时性要求高SCADA / 设备采集时序数据库、Redis温度、压力、转速等点位高频写入量大ERPOracle、SAP 系数据库物料、BOM、销售订单会计口径变动慢这些系统各自服务于自己的业务闭环时没问题但一旦需要“工单维度的良率报表”或者“某批次产品的完整生产追溯”数据就散落在至少两个库里。一个简单的查询比如“查出 6 月所有不合格品对应的产品名称和生产线下线”就涉及到 QMS 的检验表、MES 的工单表甚至还要关联 ERP 的物料主数据。此时最大的障碍不是 SQL 写不出来而是这些表根本不在同一个数据库实例里。1.2 传统做法的三个常见做法和瓶颈面对跨库查询很多工厂实际采用的是下面三种做法各有各的代价。定时 ETL 复制到数仓或数据中台。数据团队每天凌晨把各个系统的表同步到统一数仓再建模、再提供报表。优点是口径稳定缺点也很明显数据至少慢半天临时加一个字段要重新同步而且很多小的跨库分析需求根本不需要动用整套中台。在应用层写代码逐个系统取数。让开发人员调用 MES 的接口取工单调用 QMS 的接口取检验记录再在内存里做匹配和聚合。数据源一多就会出现 N 个系统乘 N 个接口的组合问题接口慢、字段变化、联调成本都压在应用层。导出 Excel 后用 VLOOKUP 手工匹配。这是工厂里最常见的“民间方案”适合小批量、一次性、要写得少的数据核对。但数据量超过几十万行、或者需要每天重复查询时Excel 的内存和处理能力很快顶不住版本还会失控。这些方案本身没有错但都默认了一件事情必须先让数据搬家才能做联合查询。联邦查询换了一个角度数据不搬家查询直接到原库去取。1.3 联邦查询的定义和收益联邦查询是指通过一个统一查询引擎以标准 SQL 同时连接多个异构数据源让用户像查询本地单表一样查询跨系统数据而数据本身仍然留在原数据库中。查询引擎负责把 SQL 拆分、把能下推的计算下推到各数据源执行再把结果合并返回。这个设计带来的直接收益是数据不复制不产生双份存储也不会因为同步延迟导致“数仓里的数据和业务系统对不上”。查询实时性更好读到的是源库当前数据而不是昨天晚上的快照。统一 SQL 入口数据分析师不用关心目标表在 MySQL 还是 PostgreSQL只需要知道 catalog、schema 和表名。权限可以收敛到查询引擎这一层配合源库账号的最小授权能形成统一的数据访问面。但也要清醒一点联邦查询不是银弹。它更适合跨系统临时取数、轻量级集成和探查式分析不适合把 TB 级大表的复杂报表全部压在联邦查询上。后面会专门讲它和数仓、湖仓的关系。2. 联邦查询是怎么把“多个库”变成“一张表”的2.1 三级命名catalog.schema.table理解联邦查询首先要理解它的三级命名规则。以 Trino 为例一个完整表名是catalog.schema.table三段式catalog对应一个数据源连接配置相当于给 MySQL、PostgreSQL、Iceberg 各起一个名字。schema对应数据源里的逻辑空间MySQL 里通常对应数据库名PostgreSQL 里对应 schema。table对应该空间下的具体表。启动 Trino 后可以用下面两条命令确认数据源是否接入成功SHOW CATALOGS; SHOW TABLES FROM mysql.quality_db;第一句会列出所有 catalog第二句会列出 MySQL 的quality_db库下有哪些表。这样设计的好处是应用层只认一套三级命名底层数据源切换、扩容、迁移都可以通过修改 catalog 配置来隔离。2.2 查询下推与结果合并联邦查询的执行过程可以简化为两个阶段下推Pushdown和合并Coordinator Aggregation。下推是指查询引擎把自己能识别的过滤条件、投影列、甚至部分聚合计算转换成数据源自己的 SQL让数据源先做一层加工。例如这条查询SELECT order_no, product_barcode, result FROM mysql.quality_db.quality_records WHERE result NG;Trino 的 MySQL 连接器会尽量把它转换成对 MySQL 的查询让 MySQL 先按result NG过滤只返回必要列。这样网络上传回的数据量就不是整张表而是过滤后的少量记录。合并发生在查询引擎的协调节点当两个数据源各自返回中间结果后引擎再按照 join 条件、聚合逻辑、排序和 limit 做最后处理。跨库 join 之所以比单库 join 慢通常不是因为引擎不会算而是因为过滤条件没有下推导致大量数据被拉到引擎内存里。join 字段在源库没有索引源库执行时只能全表扫描。查询里对字段做了函数处理破坏了连接器做下推判断的基础。2.3 联邦查询不是数据中台也不是数仓很多团队会把联邦查询和数仓、数据中台混为一谈。这里用一张表说清楚边界维度定时 ETL 数仓数据湖 / 湖仓如 Iceberg联邦查询数据位置复制到数仓存储存到湖存储留在原系统数据库实时性T1 或分钟级分钟级或小时级源库当前状态口径统一能力强可以在建模时统一中依赖表格式和规范较弱依赖 SQL 层约定适合场景固定报表、大数据量分析大规模历史分析跨系统临时取数、轻量集成主要成本存储 同步任务 计算存储 计算查询引擎节点 源库查询压力联邦查询更像是一个“数据访问层”解决的是“不用搬数据也能查”的问题数仓和湖仓解决的是“搬过来之后怎么建模、怎么算大规模历史数据”的问题。两者不是替代关系而是上下游配合关系。3. 可选技术栈从数据库自带能力到分布式查询引擎3.1 数据库原生联邦能力FEDERATED 与 FDW如果跨库场景不复杂数据源数量少可以先考虑数据库自带的能力。MySQL 提供FEDERATED存储引擎可以把远程表映射成当前实例里的本地表。用法大致如下CREATE TABLE remote_quality_records ( record_id BIGINT NOT NULL, order_no VARCHAR(32), product_barcode VARCHAR(64), check_time DATETIME, result VARCHAR(8) ) ENGINEFEDERATED CONNECTIONmysql://trino:trino123192.168.1.20:3306/quality_db/quality_records;建好后可以像查本地表一样查询远程表。但这个方案限制很多很多 MySQL 发行版默认没有开启 FEDERATED 引擎它按记录方式访问远程表复杂 join 和大批量查询性能较差它也只能在 MySQL 生态内部使用。PostgreSQL 的postgres_fdw是官方自带的扩展体验比 MySQL FEDERATED 成熟不少。以两个 PostgreSQL 库为例CREATE EXTENSION IF NOT EXISTS postgres_fdw; CREATE SERVER remote_pg_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 192.168.1.21, port 5432, dbname mes_db); CREATE USER MAPPING FOR CURRENT_USER SERVER remote_pg_server OPTIONS (user trino, password trino123); IMPORT FOREIGN SCHEMA public FROM SERVER remote_pg_server INTO public;之后就能在本地 PostgreSQL 中直接 join 远程表。如果目标是连接 MySQL需要使用mysql_fdw等第三方扩展功能和稳定性依赖社区维护投入生产前需要做充分验证。原生方案适合“以某个数据库为中心、外部数据源少、数据量可控”的场景。一旦数据源超过三个、数据库类型混杂还是需要统一查询引擎。3.2 分布式查询引擎Trino 为什么适合工厂Trino 是当前联邦查询场景最常用的开源分布式 SQL 查询引擎前身是 PrestoSQL。它的核心定位就是“一个 SQL 查遍所有数据源”。Trino 通过连接器Connector机制接入各种存储关系型MySQL、PostgreSQL、SQL Server、Oracle、MariaDB。数据湖与文件Hive、Iceberg、Delta Lake、Parquet、CSV。其他Kafka、ClickHouse、Doris、Elasticsearch 等。对工厂场景而言Trino 最有价值的地方在于它不需要预先建模也不要求数据搬到同一个地方只要源库允许 JDBC 连接就能快速接入。整套环境用 Docker 就能搭起来非常适合先跑通最小示例再评估生产落地。3.3 Apache Iceberg 与联邦查询的关系最近几年“Iceberg 联邦查询”经常和联邦查询一起被提起。Iceberg 不是查询引擎也不直接解决“连多个数据库”的问题它是一种开放表格式把表结构、分区、快照、数据文件位置等元数据统一管理起来。多个引擎如 Trino、Spark、Flink 可以通过 Iceberg 读取同一批表数据。在实际架构里Iceberg 更多承担“湖仓底座”的角色把历史明细数据放在 Iceberg 表里Trino 配置一个 Iceberg catalog再让 Trino 在同一句 SQL 里去 join Iceberg 表和 MySQL 业务表。这样既保留了冷数据的大规模分析能力又能和实时业务系统做联合查询属于联邦查询一种典型的进阶形态。3.4 选型对照表方案接入数据源数量实时性实现成本适合工厂场景MySQL FEDERATED少仅 MySQL 系实时低两个 MySQL 实例之间简单查PostgreSQL FDW少到中实时低以 PostgreSQL 为中心的小规模集成Trino 联邦查询多、异构近实时中MES、QMS、WMS、IoT 多系统轻量集成Trino Iceberg 湖仓多源 历史大表分钟级高历史分析 实时业务库联合查询全量 ETL 数仓多源T1高固定报表、大数据量分析4. 最小可复现实验跨 MySQL 和 PostgreSQL 联查生产质量数据4.1 实验目标与数据模型实验模拟工厂里最常做的“不合格品按工单归集”源 AMySQL 的quality_db.quality_records保存质量检验记录。源 BPostgreSQL 的mes_db.public.production_orders保存生产工单主数据。目标查出所有结果为 NG 的检验记录并关联出对应工单的产品名和生产线下线。这个实验会用到三个容器两个数据库容器加一个 Trino 容器。用 Docker Compose 一次性启动便于复现和清理。4.2 用 Docker Compose 搭起三节点环境先创建实验目录mkdir -p factory-federation cd factory-federation mkdir -p init/mysql init/postgres trino/etc在factory-federation下创建docker-compose.ymlversion: 3.8 services: mysql: image: mysql:8.0 container_name: factory-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: quality_db MYSQL_USER: trino MYSQL_PASSWORD: trino123 ports: - 3306:3306 volumes: - ./init/mysql:/docker-entrypoint-initdb.d postgres: image: postgres:15 container_name: factory-postgres environment: POSTGRES_USER: trino POSTGRES_PASSWORD: trino123 POSTGRES_DB: mes_db ports: - 5432:5432 volumes: - ./init/postgres:/docker-entrypoint-initdb.d trino: image: trinodb/trino:latest container_name: factory-trino depends_on: - mysql - postgres ports: - 8080:8080 volumes: - ./trino/etc:/etc/trinoMySQL 和 PostgreSQL 官方镜像都会在首次初始化数据卷时执行docker-entrypoint-initdb.d下的 SQL 脚本所以把建表和数据脚本放进去即可。注意如果修改了 SQL 脚本需要删除数据卷重新初始化命令是docker compose down -v实验环境可以这样重置生产环境不要随意删卷。4.3 准备两个库的模拟数据与账号创建init/mysql/01_create_quality.sql内容如下CREATE DATABASE IF NOT EXISTS quality_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE quality_db; CREATE TABLE quality_records ( record_id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, product_barcode VARCHAR(64) NOT NULL, check_time DATETIME NOT NULL, result VARCHAR(8) NOT NULL, defect_code VARCHAR(16), worker VARCHAR(32), INDEX idx_order_no (order_no), INDEX idx_check_time (check_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO quality_records (order_no, product_barcode, check_time, result, defect_code, worker) VALUES (MO-2025-0001, BARCODE-001, 2025-06-01 08:30:00, OK, NULL, 王工), (MO-2025-0001, BARCODE-002, 2025-06-01 08:42:00, NG, D-101, 王工), (MO-2025-0002, BARCODE-003, 2025-06-01 09:10:00, NG, D-202, 李工); CREATE USER trino% IDENTIFIED BY trino123; GRANT SELECT ON quality_db.* TO trino%;创建init/postgres/01_create_orders.sql内容如下CREATE TABLE IF NOT EXISTS public.production_orders ( order_no VARCHAR(32) PRIMARY KEY, product_name VARCHAR(64) NOT NULL, production_line VARCHAR(32) NOT NULL, plan_qty INT NOT NULL, order_date DATE NOT NULL ); INSERT INTO public.production_orders (order_no, product_name, production_line, plan_qty, order_date) VALUES (MO-2025-0001, 控制面板 A40, 一号线, 500, 2025-05-28), (MO-2025-0002, 控制面板 A41, 一号线, 300, 2025-05-30), (MO-2025-0003, 传感器模组 S20, 二号线, 1000, 2025-06-01); CREATE USER trino WITH PASSWORD trino123; GRANT CONNECT ON DATABASE mes_db TO trino; GRANT USAGE ON SCHEMA public TO trino; GRANT SELECT ON ALL TABLES IN SCHEMA public TO trino;这里特意不给 Trino 账号写权限因为查询引擎只需要读。生产环境同样应遵循最小权限原则。4.4 配置 Trino 并启动验证在trino/etc下准备四个文件。首先是config.propertiescoordinatortrue node-scheduler.include-coordinatortrue http-server.http.port8080 query.max-memory2GB query.max-memory-per-node1GB discovery.urihttp://localhost:8080node.propertiesnode.environmentproduction node.idffffffff-ffff-ffff-ffff-ffffffffffff node.data-dir/data/trinojvm.config-server -Xmx2G -XX:InitialRAMPercentage80 -XX:MaxRAMPercentage80 -XX:UseG1GC -XX:G1HeapRegionSize32M -XX:ExplicitGCInvokesConcurrent -XX:HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryErrorkill -9 %plog.propertiesio.trinoINFO然后创建两个 catalog 文件。trino/etc/catalog/mysql.propertiesconnector.namemysql connection-urljdbc:mysql://mysql:3306 connection-usertrino connection-passwordtrino123trino/etc/catalog/postgresql.propertiesconnector.namepostgresql connection-urljdbc:postgresql://postgres:5432/mes_db connection-usertrino connection-passwordtrino123注意Trino 容器内访问 MySQL 和 PostgreSQL要使用 Compose 服务名mysql和postgres不能用localhost。另外挂载配置目录时要注意容器内用户对目录的读权限遇到 Permission denied先检查trino/etc下文件的权限是否可读。启动环境docker compose up -d docker compose ps进入 Trino 命令行docker exec -it factory-trino trino先验证 catalogSHOW CATALOGS; SHOW TABLES FROM mysql.quality_db; SHOW TABLES FROM postgresql.mes.public;正常会看到mysql、postgresql、system三个 catalog以及两个库下的表。再分别确认两边能独立查询SELECT count(*) FROM mysql.quality_db.quality_records; SELECT count(*) FROM postgresql.mes.public.production_orders;4.5 执行真正的跨库关联查询下面这条 SQL 就是本文的核心实验。它把 MySQL 里的质量检验记录和 PostgreSQL 里的生产工单按order_no关联起来SELECT q.order_no, p.product_name, p.production_line, q.product_barcode, q.check_time, q.result, q.defect_code FROM mysql.quality_db.quality_records q LEFT JOIN postgresql.mes.public.production_orders p ON q.order_no p.order_no WHERE q.check_time TIMESTAMP 2025-06-01 00:00:00 AND q.check_time TIMESTAMP 2025-06-02 00:00:00 AND q.result NG ORDER BY q.check_time DESC LIMIT 100;预期结果类似order_noproduct_nameproduction_lineproduct_barcodecheck_timeresultdefect_codeMO-2025-0002控制面板 A41一号线BARCODE-0032025-06-01 09:10:00NGD-202MO-2025-0001控制面板 A40一号线BARCODE-0022025-06-01 08:42:00NGD-101执行这条 SQL 时Trino 会同时连到两个数据库各自取数后在协调节点完成 join。由于我们把时间范围和result NG都写在了查询条件里这两个过滤能被下推到 MySQLMySQL 只需要返回很少的记录。这就是为什么“跨库查询慢不慢很大程度取决于条件能不能下推”。5. 关键配置与 SQL 解释为什么这样查能快一些5.1 Catalog 连接参数速查以 Trino 的 MySQL、PostgreSQL 连接器为例常用属性如下不同版本之间可能略有差异部署前以对应版本文档为准参数含义示例说明connector.name连接器类型mysql、postgresql决定 SQL 方言转换和类型映射connection-urlJDBC 连接地址jdbc:mysql://mysql:3306容器间用服务名生产用内网域名connection-userJDBC 用户名trino建议只读账号connection-passwordJDBC 密码trino123生产环境使用密钥管理case-insensitive-name-matching是否忽略表名字母大小写true / false源库存在混合大小写对象时开启connection-timeout连接超时时间30s防止源库不可用时长时间阻塞query.timeout 或资源组限制查询超时控制按业务约定防止大查询长期占用源库连接生产环境至少要做两个动作连接串里不写明文密码给查询设置超时和资源上限。否则一条写坏的 SQL 就能把源库连接池打满。5.2 谓词下推过滤发生在数据源而不是引擎内存前面实验里的WHERE条件就是典型的谓词下推。为了验证某个条件是否真的下推可以用 Trino 的 EXPLAIN 命令EXPLAIN (TYPE DISTRIBUTED) SELECT q.product_barcode, p.product_name FROM mysql.quality_db.quality_records q LEFT JOIN postgresql.mes.public.production_orders p ON q.order_no p.order_no WHERE q.result NG;执行后计划里通常会看到两个数据源各自形成独立的读取片段MySQL 片段上的扫描节点会带上result NG的过滤语义而不是把整张表全部搬运到 Trino。不同版本的算子名称会有差异关键判断标准是数据源侧先过滤再返回引擎。如果发现某些查询条件没有下推问题通常出在写法上对列做了函数运算、隐式类型转换、或者使用了连接器不支持下推的复杂表达式。处理办法是把功能型写法改写成“列范围型”写法。5.3 影响性能的常见写法对比写法问题推荐写法SELECT * FROM 表把无关列全拉回引擎只选需要的列WHERE DATE(check_time) 2025-06-01列上套函数破坏索引和下推check_time 2025-06-01 AND check_time 2025-06-02大表 join 时无 limit 全量返回结果集过大先加LIMIT 100探查再按条件缩小范围join key 两边字符集或类型不一致匹配不上或隐式转换统一字段类型、长度必要时显式CAST不设置超时和资源组慢查询拖垮源库和引擎配置查询超时、并发限制和内存上限5.4 查询引擎账号要最小权限实验里已经演示了给 Trino 建只读账号。生产环境还应该做到MySQL 侧只授权目标库的SELECT不要使用 root。PostgreSQL 侧只授权CONNECT、USAGE和SELECT。每个环境使用独立账号密码轮换通过密钥系统完成。如果需要查询多张表逐表授权或按 schema 授权避免SELECT ... , *的权限扩散。MySQL 账号授权示例CREATE USER trino% IDENTIFIED BY strong_password; GRANT SELECT ON quality_db.* TO trino%;PostgreSQL 账号授权示例CREATE USER trino WITH PASSWORD strong_password; GRANT CONNECT ON DATABASE mes_db TO trino; GRANT USAGE ON SCHEMA public TO trino; GRANT SELECT ON ALL TABLES IN SCHEMA public TO trino;6. 工厂生产落地时哪些坑最值得提前规避6.1 单库查很快、联邦查很慢的根因一种高频现象是直接连 MySQL 查某张表很快但通过 Trino 跨库 join 后变慢。常见根因有三个。第一join key 在源库没有索引。比如quality_records.order_no没有建索引MySQL 只能全表扫描。解决办法是在两边数据库的常用关联字段上建索引。第二过滤条件没有下推整表数据被拉回 Trino。这通常是因为 SQL 写法让连接器无法识别过滤表达式按 5.3 的表格调整写法即可。第三一次查询跨了两张很大的表且没有时间范围或业务维度缩小数据量。联邦查询的定位是轻量级取数如果业务确实需要全量大表关联应该考虑把历史数据放进 Iceberg 或数仓而不是长期压着线上关系库。6.2 时区、字符集和数值精度陷阱跨库查询最容易出现三类“看不见的差异”时区MySQL 的DATETIME不带时区信息PostgreSQL 的timestamptz带时区。两边直接比较时经常出现相差 8 小时的问题。统一做法是新表统一存 UTC展示层再转换。字符集MySQL 如果使用latin1中文会出现乱码。接入前要确认源表字符集推荐统一为utf8mb4连接 URL 里也显式声明 UTF-8。数值精度数量、重量、金额不要用浮点数数据库用DECIMAL例如DECIMAL(20,6)。比例和单价字段最容易因为类型不一致导致 join 结果偏差。这些差异在单库查询时不容易暴露一旦跨库 join两边类型语义不同就会立刻变成脏数据。6.3 别把在线 OLTP 系统压垮联邦查询直接访问业务系统数据库本质上是给 OTLP 系统增加查询负载。生产落地需要做几层保护查询引擎账号只读且只授予业务需要的库表。对源库设置慢查询日志和连接数告警观察 Trino 是否把某个表的查询打到源库。Trino 侧配置资源组限制并发、内存和扫描行数。临时分析场景可以限制单查询最多扫描的数据量。对高频固定查询不要反复走联邦查询可以让源库先提供只读从库或者把结果落到明细表再查询。6.4 报表走数仓临时分析走联邦判断一个需求该走联邦查询还是数仓可以从三个问题入手这个查询每天发生多少次高频固定查询应该进数仓或湖仓。数据量是否达到千万行以上大表全量分析更适合 Iceberg 或数仓。对实时性要求有多高需要看业务系统当前状态的走联邦只需要看趋势的T1 数仓足够。正确分工是业务系统原库负责日常事务联邦查询负责跨系统取数和轻量分析数据湖仓负责大规模历史计算。三者分层配合而不是互相替代。6.5 上线前可复用的排查清单[ ] 每个数据源是否都使用只读账号且账号权限只覆盖必要库表。[ ] 网络白名单是否已放开生产环境是否启用 TLS。[ ] 连接密码是否已经纳入密钥管理代码和配置文件中没有明文。[ ]join字段和常用时间字段在源库是否已建索引。[ ] 是否用EXPLAIN验证过主要查询的谓词下推。[ ] 两边时区和字符集是否一致。[ ] 是否已配置查询超时、资源组和连接池限制。[ ] 是否模拟过一次大表全量扫描确认不会压垮源库。[ ] 是否已经添加源库连接数、慢查询、Trino 内存和查询耗时的监控。7. 常见问题与排查路径7.1 高频问题速查表问题现象常见原因检查方式处理建议SHOW CATALOGS看不到某个 catalogcatalog 配置文件没生效或文件名拼写错误检查etc/catalog/*.properties文件名和内容文件名必须以.properties结尾修改后重启 Trino连接被拒Connection refused网络不通、端口未开、账号不允许来源 IP在数据库容器内看日志从 Trino 容器验证连通调整网络策略使用可达的内网地址中文乱码源库字符集与查询会话不一致在源库查询SHOW CREATE TABLEMySQL 统一改为utf8mb4连接 URL 指定 UTF-8时间相差 8 小时DATETIME和timestamptz混用分别在两边执行SELECT now()对比统一存 UTC展示层转换跨库 join 结果重复join key 在某一侧不是唯一键分别执行SELECT order_no, count(*) GROUP BY order_no HAVING count(*)1根据业务口径选择唯一关系必要时先聚合去重查询特别慢条件未下推、缺索引、全表扫描执行EXPLAIN查看计划建索引、改写条件为范围查询、加 LIMIT字段类型不匹配报错两边类型不一致如INT对VARCHAR查看两边SHOW CREATE TABLE显式CAST或统一数据模型查询内存不足或超时一次拉取过多数据查看 Trino 查询状态和日志缩小时间范围分批查询限制扫描量7.2 一条通用的联邦查询排查链路联邦查询的排错顺序比具体报错更重要推荐按下面链路逐层检查先单库验证。把 SQL 拆成各自数据源的部分在原库客户端单独执行确认单库本身没问题。检查 catalog 连通性。执行SHOW CATALOGS、SHOW TABLES FROM catalog.schema确认元数据可见。跑最小查询。用SELECT count(*) FROM catalog.schema.table WHERE ...验证过滤条件下推后的基础性能。再跑跨源 join。先加LIMIT 10确认关联逻辑正确。查看执行计划。用EXPLAIN (TYPE DISTRIBUTED)确认是否出现数据源侧过滤。查看源库日志。确认没有全表扫描、没有异常慢查询。最后核对时区、字符集和字段类型。这三类差异往往在结果正确性层面暴露而不是在报错层面。8. 最佳实践与下一步扩展方向8.1 联邦查询落地的四个可执行原则第一能下推就下推。写 SQL 时优先用列范围条件少在过滤条件里对列套函数查询只选必要字段。第二查询面就是权限面。联邦查询把很多原来“导出 Excel 后失控”的数据访问收回到统一引擎账号必须只读、最小化、可审计。第三区分取数任务和分析任务。跨系统取数用联邦查询固定报表和大规模分析进数仓或 Iceberg不要让联邦查询长期承担重型计算。第四先小后大。先选一个痛点场景跑通比如“不合格品按工单归集”再逐步接入 WMS、ERP 和时序库不要一开始就追求把所有系统全部联邦化。8.2 从联邦查询走向“湖仓一体 联邦入口”一个可行的进阶架构是业务系统的实时数据继续留在原库历史明细和需要大规模分析的冷数据进入 Iceberg 表Trino 上层同时配置 MySQL、PostgreSQL、Iceberg 等 catalog。数据使用者只接触 Trino 的 SQL 入口不需要知道某张表到底在业务库还是在数据湖。这种架构的好处是既保留了实时业务查询的灵敏性又让历史数据分析获得湖仓的扩展能力。实现时需要注意两点一是离线入库任务的延迟要匹配分析时效要求二是 Trino 的 catalog 命名要稳定避免表名频繁变更导致下游混乱。8.3 给初学者和工厂数据组的练习路径第一阶段用 PostgreSQL 的postgres_fdw连接第二个 PostgreSQL理解“外部表”的概念。第二阶段复现本文的 Docker Compose 实验跑通 MySQL 加 PostgreSQL 的跨库 join。第三阶段增加第三个数据源比如把一张历史大表放到 Iceberg 中再写同一句 SQL join 三个 catalog。第四阶段使用EXPLAIN反复改写 SQL训练自己判断“条件是否下推、索引是否生效”。第五阶段加入权限、资源组、监控和告警形成可上线的最小联邦查询规范。联邦查询真正值钱的地方不是省掉了 ETL 那几步而是让工厂在数据仍然分散的情况下先获得统一的取数入口。很多企业的首要问题不是“数据没有集中”而是“根本不知道数据在哪、怎么安全地把它查出来”。用最小实验跑通联邦查询之后你会对每个数据源的查询压力、SQL 下推、权限边界都有更具体的判断这种能力比记住任何工具的命令都更有用。下一步再结合 Iceberg 或数仓去沉淀已经稳定的分析模型就能逐步把“临时能查”升级成“长期好用”的工厂数据底座。
联邦查询跨库实战：用SQL关联MySQL与PostgreSQL
在工厂信息化建设里最常被吐槽的一句话往往是“数据都有但查不出来”。生产订单在 MES 里质量检验在 QMS 里原材料入库在 WMS 里设备参数又落在 SCADA 或时序库里系统之间数据格式不同、数据库不同甚至服务器也不同。质量人员想按工单把检验结果、生产批次、设备参数放在一起看要么等数据团队导数据要么自己导 Excel 再 VLOOKUP过程慢也容易出错。联邦查询Federated Query就是解决这类问题的思路不用先把数据搬到一起而是让同一个 SQL 引擎直接连接多个数据源把“跨库跨表查询”变成一条 SQL 就能完成的事情。本文面向制造企业的数据分析师、数据开发工程师和信息化负责人会用最小实验把 MySQL 里的质量检验表和 PostgreSQL 里的生产工单表做跨库关联再讲清楚查询下推、结果合并、权限控制以及生产落地时需要注意的问题。1. 工厂数据查询难难在数据根本不在一个库1.1 一个典型的工厂数据分布案例制造企业往往不是缺系统而是系统太多。每个业务部门都有自己习惯的软件和数据库MES 记录工单和报工QMS 记录质量检验和缺陷WMS 管理原材料和成品出入库SCADA 或工业时序库保存设备点位数据ERP 保存物料、BOM 和订单。下面是一张很常见的工厂数据分布表业务系统常见数据库典型数据数据特征MES 制造执行系统PostgreSQL、SQL Server工单、工艺路线、报工记录结构化写入频繁QMS 质量管理系统MySQL、Oracle检验记录、缺陷代码、不合格品高频插入按时间查询WMS 仓储系统SQL Server、MySQL出入库记录、库存快照实时性要求高SCADA / 设备采集时序数据库、Redis温度、压力、转速等点位高频写入量大ERPOracle、SAP 系数据库物料、BOM、销售订单会计口径变动慢这些系统各自服务于自己的业务闭环时没问题但一旦需要“工单维度的良率报表”或者“某批次产品的完整生产追溯”数据就散落在至少两个库里。一个简单的查询比如“查出 6 月所有不合格品对应的产品名称和生产线下线”就涉及到 QMS 的检验表、MES 的工单表甚至还要关联 ERP 的物料主数据。此时最大的障碍不是 SQL 写不出来而是这些表根本不在同一个数据库实例里。1.2 传统做法的三个常见做法和瓶颈面对跨库查询很多工厂实际采用的是下面三种做法各有各的代价。定时 ETL 复制到数仓或数据中台。数据团队每天凌晨把各个系统的表同步到统一数仓再建模、再提供报表。优点是口径稳定缺点也很明显数据至少慢半天临时加一个字段要重新同步而且很多小的跨库分析需求根本不需要动用整套中台。在应用层写代码逐个系统取数。让开发人员调用 MES 的接口取工单调用 QMS 的接口取检验记录再在内存里做匹配和聚合。数据源一多就会出现 N 个系统乘 N 个接口的组合问题接口慢、字段变化、联调成本都压在应用层。导出 Excel 后用 VLOOKUP 手工匹配。这是工厂里最常见的“民间方案”适合小批量、一次性、要写得少的数据核对。但数据量超过几十万行、或者需要每天重复查询时Excel 的内存和处理能力很快顶不住版本还会失控。这些方案本身没有错但都默认了一件事情必须先让数据搬家才能做联合查询。联邦查询换了一个角度数据不搬家查询直接到原库去取。1.3 联邦查询的定义和收益联邦查询是指通过一个统一查询引擎以标准 SQL 同时连接多个异构数据源让用户像查询本地单表一样查询跨系统数据而数据本身仍然留在原数据库中。查询引擎负责把 SQL 拆分、把能下推的计算下推到各数据源执行再把结果合并返回。这个设计带来的直接收益是数据不复制不产生双份存储也不会因为同步延迟导致“数仓里的数据和业务系统对不上”。查询实时性更好读到的是源库当前数据而不是昨天晚上的快照。统一 SQL 入口数据分析师不用关心目标表在 MySQL 还是 PostgreSQL只需要知道 catalog、schema 和表名。权限可以收敛到查询引擎这一层配合源库账号的最小授权能形成统一的数据访问面。但也要清醒一点联邦查询不是银弹。它更适合跨系统临时取数、轻量级集成和探查式分析不适合把 TB 级大表的复杂报表全部压在联邦查询上。后面会专门讲它和数仓、湖仓的关系。2. 联邦查询是怎么把“多个库”变成“一张表”的2.1 三级命名catalog.schema.table理解联邦查询首先要理解它的三级命名规则。以 Trino 为例一个完整表名是catalog.schema.table三段式catalog对应一个数据源连接配置相当于给 MySQL、PostgreSQL、Iceberg 各起一个名字。schema对应数据源里的逻辑空间MySQL 里通常对应数据库名PostgreSQL 里对应 schema。table对应该空间下的具体表。启动 Trino 后可以用下面两条命令确认数据源是否接入成功SHOW CATALOGS; SHOW TABLES FROM mysql.quality_db;第一句会列出所有 catalog第二句会列出 MySQL 的quality_db库下有哪些表。这样设计的好处是应用层只认一套三级命名底层数据源切换、扩容、迁移都可以通过修改 catalog 配置来隔离。2.2 查询下推与结果合并联邦查询的执行过程可以简化为两个阶段下推Pushdown和合并Coordinator Aggregation。下推是指查询引擎把自己能识别的过滤条件、投影列、甚至部分聚合计算转换成数据源自己的 SQL让数据源先做一层加工。例如这条查询SELECT order_no, product_barcode, result FROM mysql.quality_db.quality_records WHERE result NG;Trino 的 MySQL 连接器会尽量把它转换成对 MySQL 的查询让 MySQL 先按result NG过滤只返回必要列。这样网络上传回的数据量就不是整张表而是过滤后的少量记录。合并发生在查询引擎的协调节点当两个数据源各自返回中间结果后引擎再按照 join 条件、聚合逻辑、排序和 limit 做最后处理。跨库 join 之所以比单库 join 慢通常不是因为引擎不会算而是因为过滤条件没有下推导致大量数据被拉到引擎内存里。join 字段在源库没有索引源库执行时只能全表扫描。查询里对字段做了函数处理破坏了连接器做下推判断的基础。2.3 联邦查询不是数据中台也不是数仓很多团队会把联邦查询和数仓、数据中台混为一谈。这里用一张表说清楚边界维度定时 ETL 数仓数据湖 / 湖仓如 Iceberg联邦查询数据位置复制到数仓存储存到湖存储留在原系统数据库实时性T1 或分钟级分钟级或小时级源库当前状态口径统一能力强可以在建模时统一中依赖表格式和规范较弱依赖 SQL 层约定适合场景固定报表、大数据量分析大规模历史分析跨系统临时取数、轻量集成主要成本存储 同步任务 计算存储 计算查询引擎节点 源库查询压力联邦查询更像是一个“数据访问层”解决的是“不用搬数据也能查”的问题数仓和湖仓解决的是“搬过来之后怎么建模、怎么算大规模历史数据”的问题。两者不是替代关系而是上下游配合关系。3. 可选技术栈从数据库自带能力到分布式查询引擎3.1 数据库原生联邦能力FEDERATED 与 FDW如果跨库场景不复杂数据源数量少可以先考虑数据库自带的能力。MySQL 提供FEDERATED存储引擎可以把远程表映射成当前实例里的本地表。用法大致如下CREATE TABLE remote_quality_records ( record_id BIGINT NOT NULL, order_no VARCHAR(32), product_barcode VARCHAR(64), check_time DATETIME, result VARCHAR(8) ) ENGINEFEDERATED CONNECTIONmysql://trino:trino123192.168.1.20:3306/quality_db/quality_records;建好后可以像查本地表一样查询远程表。但这个方案限制很多很多 MySQL 发行版默认没有开启 FEDERATED 引擎它按记录方式访问远程表复杂 join 和大批量查询性能较差它也只能在 MySQL 生态内部使用。PostgreSQL 的postgres_fdw是官方自带的扩展体验比 MySQL FEDERATED 成熟不少。以两个 PostgreSQL 库为例CREATE EXTENSION IF NOT EXISTS postgres_fdw; CREATE SERVER remote_pg_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 192.168.1.21, port 5432, dbname mes_db); CREATE USER MAPPING FOR CURRENT_USER SERVER remote_pg_server OPTIONS (user trino, password trino123); IMPORT FOREIGN SCHEMA public FROM SERVER remote_pg_server INTO public;之后就能在本地 PostgreSQL 中直接 join 远程表。如果目标是连接 MySQL需要使用mysql_fdw等第三方扩展功能和稳定性依赖社区维护投入生产前需要做充分验证。原生方案适合“以某个数据库为中心、外部数据源少、数据量可控”的场景。一旦数据源超过三个、数据库类型混杂还是需要统一查询引擎。3.2 分布式查询引擎Trino 为什么适合工厂Trino 是当前联邦查询场景最常用的开源分布式 SQL 查询引擎前身是 PrestoSQL。它的核心定位就是“一个 SQL 查遍所有数据源”。Trino 通过连接器Connector机制接入各种存储关系型MySQL、PostgreSQL、SQL Server、Oracle、MariaDB。数据湖与文件Hive、Iceberg、Delta Lake、Parquet、CSV。其他Kafka、ClickHouse、Doris、Elasticsearch 等。对工厂场景而言Trino 最有价值的地方在于它不需要预先建模也不要求数据搬到同一个地方只要源库允许 JDBC 连接就能快速接入。整套环境用 Docker 就能搭起来非常适合先跑通最小示例再评估生产落地。3.3 Apache Iceberg 与联邦查询的关系最近几年“Iceberg 联邦查询”经常和联邦查询一起被提起。Iceberg 不是查询引擎也不直接解决“连多个数据库”的问题它是一种开放表格式把表结构、分区、快照、数据文件位置等元数据统一管理起来。多个引擎如 Trino、Spark、Flink 可以通过 Iceberg 读取同一批表数据。在实际架构里Iceberg 更多承担“湖仓底座”的角色把历史明细数据放在 Iceberg 表里Trino 配置一个 Iceberg catalog再让 Trino 在同一句 SQL 里去 join Iceberg 表和 MySQL 业务表。这样既保留了冷数据的大规模分析能力又能和实时业务系统做联合查询属于联邦查询一种典型的进阶形态。3.4 选型对照表方案接入数据源数量实时性实现成本适合工厂场景MySQL FEDERATED少仅 MySQL 系实时低两个 MySQL 实例之间简单查PostgreSQL FDW少到中实时低以 PostgreSQL 为中心的小规模集成Trino 联邦查询多、异构近实时中MES、QMS、WMS、IoT 多系统轻量集成Trino Iceberg 湖仓多源 历史大表分钟级高历史分析 实时业务库联合查询全量 ETL 数仓多源T1高固定报表、大数据量分析4. 最小可复现实验跨 MySQL 和 PostgreSQL 联查生产质量数据4.1 实验目标与数据模型实验模拟工厂里最常做的“不合格品按工单归集”源 AMySQL 的quality_db.quality_records保存质量检验记录。源 BPostgreSQL 的mes_db.public.production_orders保存生产工单主数据。目标查出所有结果为 NG 的检验记录并关联出对应工单的产品名和生产线下线。这个实验会用到三个容器两个数据库容器加一个 Trino 容器。用 Docker Compose 一次性启动便于复现和清理。4.2 用 Docker Compose 搭起三节点环境先创建实验目录mkdir -p factory-federation cd factory-federation mkdir -p init/mysql init/postgres trino/etc在factory-federation下创建docker-compose.ymlversion: 3.8 services: mysql: image: mysql:8.0 container_name: factory-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: quality_db MYSQL_USER: trino MYSQL_PASSWORD: trino123 ports: - 3306:3306 volumes: - ./init/mysql:/docker-entrypoint-initdb.d postgres: image: postgres:15 container_name: factory-postgres environment: POSTGRES_USER: trino POSTGRES_PASSWORD: trino123 POSTGRES_DB: mes_db ports: - 5432:5432 volumes: - ./init/postgres:/docker-entrypoint-initdb.d trino: image: trinodb/trino:latest container_name: factory-trino depends_on: - mysql - postgres ports: - 8080:8080 volumes: - ./trino/etc:/etc/trinoMySQL 和 PostgreSQL 官方镜像都会在首次初始化数据卷时执行docker-entrypoint-initdb.d下的 SQL 脚本所以把建表和数据脚本放进去即可。注意如果修改了 SQL 脚本需要删除数据卷重新初始化命令是docker compose down -v实验环境可以这样重置生产环境不要随意删卷。4.3 准备两个库的模拟数据与账号创建init/mysql/01_create_quality.sql内容如下CREATE DATABASE IF NOT EXISTS quality_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE quality_db; CREATE TABLE quality_records ( record_id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, product_barcode VARCHAR(64) NOT NULL, check_time DATETIME NOT NULL, result VARCHAR(8) NOT NULL, defect_code VARCHAR(16), worker VARCHAR(32), INDEX idx_order_no (order_no), INDEX idx_check_time (check_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; INSERT INTO quality_records (order_no, product_barcode, check_time, result, defect_code, worker) VALUES (MO-2025-0001, BARCODE-001, 2025-06-01 08:30:00, OK, NULL, 王工), (MO-2025-0001, BARCODE-002, 2025-06-01 08:42:00, NG, D-101, 王工), (MO-2025-0002, BARCODE-003, 2025-06-01 09:10:00, NG, D-202, 李工); CREATE USER trino% IDENTIFIED BY trino123; GRANT SELECT ON quality_db.* TO trino%;创建init/postgres/01_create_orders.sql内容如下CREATE TABLE IF NOT EXISTS public.production_orders ( order_no VARCHAR(32) PRIMARY KEY, product_name VARCHAR(64) NOT NULL, production_line VARCHAR(32) NOT NULL, plan_qty INT NOT NULL, order_date DATE NOT NULL ); INSERT INTO public.production_orders (order_no, product_name, production_line, plan_qty, order_date) VALUES (MO-2025-0001, 控制面板 A40, 一号线, 500, 2025-05-28), (MO-2025-0002, 控制面板 A41, 一号线, 300, 2025-05-30), (MO-2025-0003, 传感器模组 S20, 二号线, 1000, 2025-06-01); CREATE USER trino WITH PASSWORD trino123; GRANT CONNECT ON DATABASE mes_db TO trino; GRANT USAGE ON SCHEMA public TO trino; GRANT SELECT ON ALL TABLES IN SCHEMA public TO trino;这里特意不给 Trino 账号写权限因为查询引擎只需要读。生产环境同样应遵循最小权限原则。4.4 配置 Trino 并启动验证在trino/etc下准备四个文件。首先是config.propertiescoordinatortrue node-scheduler.include-coordinatortrue http-server.http.port8080 query.max-memory2GB query.max-memory-per-node1GB discovery.urihttp://localhost:8080node.propertiesnode.environmentproduction node.idffffffff-ffff-ffff-ffff-ffffffffffff node.data-dir/data/trinojvm.config-server -Xmx2G -XX:InitialRAMPercentage80 -XX:MaxRAMPercentage80 -XX:UseG1GC -XX:G1HeapRegionSize32M -XX:ExplicitGCInvokesConcurrent -XX:HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryErrorkill -9 %plog.propertiesio.trinoINFO然后创建两个 catalog 文件。trino/etc/catalog/mysql.propertiesconnector.namemysql connection-urljdbc:mysql://mysql:3306 connection-usertrino connection-passwordtrino123trino/etc/catalog/postgresql.propertiesconnector.namepostgresql connection-urljdbc:postgresql://postgres:5432/mes_db connection-usertrino connection-passwordtrino123注意Trino 容器内访问 MySQL 和 PostgreSQL要使用 Compose 服务名mysql和postgres不能用localhost。另外挂载配置目录时要注意容器内用户对目录的读权限遇到 Permission denied先检查trino/etc下文件的权限是否可读。启动环境docker compose up -d docker compose ps进入 Trino 命令行docker exec -it factory-trino trino先验证 catalogSHOW CATALOGS; SHOW TABLES FROM mysql.quality_db; SHOW TABLES FROM postgresql.mes.public;正常会看到mysql、postgresql、system三个 catalog以及两个库下的表。再分别确认两边能独立查询SELECT count(*) FROM mysql.quality_db.quality_records; SELECT count(*) FROM postgresql.mes.public.production_orders;4.5 执行真正的跨库关联查询下面这条 SQL 就是本文的核心实验。它把 MySQL 里的质量检验记录和 PostgreSQL 里的生产工单按order_no关联起来SELECT q.order_no, p.product_name, p.production_line, q.product_barcode, q.check_time, q.result, q.defect_code FROM mysql.quality_db.quality_records q LEFT JOIN postgresql.mes.public.production_orders p ON q.order_no p.order_no WHERE q.check_time TIMESTAMP 2025-06-01 00:00:00 AND q.check_time TIMESTAMP 2025-06-02 00:00:00 AND q.result NG ORDER BY q.check_time DESC LIMIT 100;预期结果类似order_noproduct_nameproduction_lineproduct_barcodecheck_timeresultdefect_codeMO-2025-0002控制面板 A41一号线BARCODE-0032025-06-01 09:10:00NGD-202MO-2025-0001控制面板 A40一号线BARCODE-0022025-06-01 08:42:00NGD-101执行这条 SQL 时Trino 会同时连到两个数据库各自取数后在协调节点完成 join。由于我们把时间范围和result NG都写在了查询条件里这两个过滤能被下推到 MySQLMySQL 只需要返回很少的记录。这就是为什么“跨库查询慢不慢很大程度取决于条件能不能下推”。5. 关键配置与 SQL 解释为什么这样查能快一些5.1 Catalog 连接参数速查以 Trino 的 MySQL、PostgreSQL 连接器为例常用属性如下不同版本之间可能略有差异部署前以对应版本文档为准参数含义示例说明connector.name连接器类型mysql、postgresql决定 SQL 方言转换和类型映射connection-urlJDBC 连接地址jdbc:mysql://mysql:3306容器间用服务名生产用内网域名connection-userJDBC 用户名trino建议只读账号connection-passwordJDBC 密码trino123生产环境使用密钥管理case-insensitive-name-matching是否忽略表名字母大小写true / false源库存在混合大小写对象时开启connection-timeout连接超时时间30s防止源库不可用时长时间阻塞query.timeout 或资源组限制查询超时控制按业务约定防止大查询长期占用源库连接生产环境至少要做两个动作连接串里不写明文密码给查询设置超时和资源上限。否则一条写坏的 SQL 就能把源库连接池打满。5.2 谓词下推过滤发生在数据源而不是引擎内存前面实验里的WHERE条件就是典型的谓词下推。为了验证某个条件是否真的下推可以用 Trino 的 EXPLAIN 命令EXPLAIN (TYPE DISTRIBUTED) SELECT q.product_barcode, p.product_name FROM mysql.quality_db.quality_records q LEFT JOIN postgresql.mes.public.production_orders p ON q.order_no p.order_no WHERE q.result NG;执行后计划里通常会看到两个数据源各自形成独立的读取片段MySQL 片段上的扫描节点会带上result NG的过滤语义而不是把整张表全部搬运到 Trino。不同版本的算子名称会有差异关键判断标准是数据源侧先过滤再返回引擎。如果发现某些查询条件没有下推问题通常出在写法上对列做了函数运算、隐式类型转换、或者使用了连接器不支持下推的复杂表达式。处理办法是把功能型写法改写成“列范围型”写法。5.3 影响性能的常见写法对比写法问题推荐写法SELECT * FROM 表把无关列全拉回引擎只选需要的列WHERE DATE(check_time) 2025-06-01列上套函数破坏索引和下推check_time 2025-06-01 AND check_time 2025-06-02大表 join 时无 limit 全量返回结果集过大先加LIMIT 100探查再按条件缩小范围join key 两边字符集或类型不一致匹配不上或隐式转换统一字段类型、长度必要时显式CAST不设置超时和资源组慢查询拖垮源库和引擎配置查询超时、并发限制和内存上限5.4 查询引擎账号要最小权限实验里已经演示了给 Trino 建只读账号。生产环境还应该做到MySQL 侧只授权目标库的SELECT不要使用 root。PostgreSQL 侧只授权CONNECT、USAGE和SELECT。每个环境使用独立账号密码轮换通过密钥系统完成。如果需要查询多张表逐表授权或按 schema 授权避免SELECT ... , *的权限扩散。MySQL 账号授权示例CREATE USER trino% IDENTIFIED BY strong_password; GRANT SELECT ON quality_db.* TO trino%;PostgreSQL 账号授权示例CREATE USER trino WITH PASSWORD strong_password; GRANT CONNECT ON DATABASE mes_db TO trino; GRANT USAGE ON SCHEMA public TO trino; GRANT SELECT ON ALL TABLES IN SCHEMA public TO trino;6. 工厂生产落地时哪些坑最值得提前规避6.1 单库查很快、联邦查很慢的根因一种高频现象是直接连 MySQL 查某张表很快但通过 Trino 跨库 join 后变慢。常见根因有三个。第一join key 在源库没有索引。比如quality_records.order_no没有建索引MySQL 只能全表扫描。解决办法是在两边数据库的常用关联字段上建索引。第二过滤条件没有下推整表数据被拉回 Trino。这通常是因为 SQL 写法让连接器无法识别过滤表达式按 5.3 的表格调整写法即可。第三一次查询跨了两张很大的表且没有时间范围或业务维度缩小数据量。联邦查询的定位是轻量级取数如果业务确实需要全量大表关联应该考虑把历史数据放进 Iceberg 或数仓而不是长期压着线上关系库。6.2 时区、字符集和数值精度陷阱跨库查询最容易出现三类“看不见的差异”时区MySQL 的DATETIME不带时区信息PostgreSQL 的timestamptz带时区。两边直接比较时经常出现相差 8 小时的问题。统一做法是新表统一存 UTC展示层再转换。字符集MySQL 如果使用latin1中文会出现乱码。接入前要确认源表字符集推荐统一为utf8mb4连接 URL 里也显式声明 UTF-8。数值精度数量、重量、金额不要用浮点数数据库用DECIMAL例如DECIMAL(20,6)。比例和单价字段最容易因为类型不一致导致 join 结果偏差。这些差异在单库查询时不容易暴露一旦跨库 join两边类型语义不同就会立刻变成脏数据。6.3 别把在线 OLTP 系统压垮联邦查询直接访问业务系统数据库本质上是给 OTLP 系统增加查询负载。生产落地需要做几层保护查询引擎账号只读且只授予业务需要的库表。对源库设置慢查询日志和连接数告警观察 Trino 是否把某个表的查询打到源库。Trino 侧配置资源组限制并发、内存和扫描行数。临时分析场景可以限制单查询最多扫描的数据量。对高频固定查询不要反复走联邦查询可以让源库先提供只读从库或者把结果落到明细表再查询。6.4 报表走数仓临时分析走联邦判断一个需求该走联邦查询还是数仓可以从三个问题入手这个查询每天发生多少次高频固定查询应该进数仓或湖仓。数据量是否达到千万行以上大表全量分析更适合 Iceberg 或数仓。对实时性要求有多高需要看业务系统当前状态的走联邦只需要看趋势的T1 数仓足够。正确分工是业务系统原库负责日常事务联邦查询负责跨系统取数和轻量分析数据湖仓负责大规模历史计算。三者分层配合而不是互相替代。6.5 上线前可复用的排查清单[ ] 每个数据源是否都使用只读账号且账号权限只覆盖必要库表。[ ] 网络白名单是否已放开生产环境是否启用 TLS。[ ] 连接密码是否已经纳入密钥管理代码和配置文件中没有明文。[ ]join字段和常用时间字段在源库是否已建索引。[ ] 是否用EXPLAIN验证过主要查询的谓词下推。[ ] 两边时区和字符集是否一致。[ ] 是否已配置查询超时、资源组和连接池限制。[ ] 是否模拟过一次大表全量扫描确认不会压垮源库。[ ] 是否已经添加源库连接数、慢查询、Trino 内存和查询耗时的监控。7. 常见问题与排查路径7.1 高频问题速查表问题现象常见原因检查方式处理建议SHOW CATALOGS看不到某个 catalogcatalog 配置文件没生效或文件名拼写错误检查etc/catalog/*.properties文件名和内容文件名必须以.properties结尾修改后重启 Trino连接被拒Connection refused网络不通、端口未开、账号不允许来源 IP在数据库容器内看日志从 Trino 容器验证连通调整网络策略使用可达的内网地址中文乱码源库字符集与查询会话不一致在源库查询SHOW CREATE TABLEMySQL 统一改为utf8mb4连接 URL 指定 UTF-8时间相差 8 小时DATETIME和timestamptz混用分别在两边执行SELECT now()对比统一存 UTC展示层转换跨库 join 结果重复join key 在某一侧不是唯一键分别执行SELECT order_no, count(*) GROUP BY order_no HAVING count(*)1根据业务口径选择唯一关系必要时先聚合去重查询特别慢条件未下推、缺索引、全表扫描执行EXPLAIN查看计划建索引、改写条件为范围查询、加 LIMIT字段类型不匹配报错两边类型不一致如INT对VARCHAR查看两边SHOW CREATE TABLE显式CAST或统一数据模型查询内存不足或超时一次拉取过多数据查看 Trino 查询状态和日志缩小时间范围分批查询限制扫描量7.2 一条通用的联邦查询排查链路联邦查询的排错顺序比具体报错更重要推荐按下面链路逐层检查先单库验证。把 SQL 拆成各自数据源的部分在原库客户端单独执行确认单库本身没问题。检查 catalog 连通性。执行SHOW CATALOGS、SHOW TABLES FROM catalog.schema确认元数据可见。跑最小查询。用SELECT count(*) FROM catalog.schema.table WHERE ...验证过滤条件下推后的基础性能。再跑跨源 join。先加LIMIT 10确认关联逻辑正确。查看执行计划。用EXPLAIN (TYPE DISTRIBUTED)确认是否出现数据源侧过滤。查看源库日志。确认没有全表扫描、没有异常慢查询。最后核对时区、字符集和字段类型。这三类差异往往在结果正确性层面暴露而不是在报错层面。8. 最佳实践与下一步扩展方向8.1 联邦查询落地的四个可执行原则第一能下推就下推。写 SQL 时优先用列范围条件少在过滤条件里对列套函数查询只选必要字段。第二查询面就是权限面。联邦查询把很多原来“导出 Excel 后失控”的数据访问收回到统一引擎账号必须只读、最小化、可审计。第三区分取数任务和分析任务。跨系统取数用联邦查询固定报表和大规模分析进数仓或 Iceberg不要让联邦查询长期承担重型计算。第四先小后大。先选一个痛点场景跑通比如“不合格品按工单归集”再逐步接入 WMS、ERP 和时序库不要一开始就追求把所有系统全部联邦化。8.2 从联邦查询走向“湖仓一体 联邦入口”一个可行的进阶架构是业务系统的实时数据继续留在原库历史明细和需要大规模分析的冷数据进入 Iceberg 表Trino 上层同时配置 MySQL、PostgreSQL、Iceberg 等 catalog。数据使用者只接触 Trino 的 SQL 入口不需要知道某张表到底在业务库还是在数据湖。这种架构的好处是既保留了实时业务查询的灵敏性又让历史数据分析获得湖仓的扩展能力。实现时需要注意两点一是离线入库任务的延迟要匹配分析时效要求二是 Trino 的 catalog 命名要稳定避免表名频繁变更导致下游混乱。8.3 给初学者和工厂数据组的练习路径第一阶段用 PostgreSQL 的postgres_fdw连接第二个 PostgreSQL理解“外部表”的概念。第二阶段复现本文的 Docker Compose 实验跑通 MySQL 加 PostgreSQL 的跨库 join。第三阶段增加第三个数据源比如把一张历史大表放到 Iceberg 中再写同一句 SQL join 三个 catalog。第四阶段使用EXPLAIN反复改写 SQL训练自己判断“条件是否下推、索引是否生效”。第五阶段加入权限、资源组、监控和告警形成可上线的最小联邦查询规范。联邦查询真正值钱的地方不是省掉了 ETL 那几步而是让工厂在数据仍然分散的情况下先获得统一的取数入口。很多企业的首要问题不是“数据没有集中”而是“根本不知道数据在哪、怎么安全地把它查出来”。用最小实验跑通联邦查询之后你会对每个数据源的查询压力、SQL 下推、权限边界都有更具体的判断这种能力比记住任何工具的命令都更有用。下一步再结合 Iceberg 或数仓去沉淀已经稳定的分析模型就能逐步把“临时能查”升级成“长期好用”的工厂数据底座。