SQL与NoSQL无法直接JOIN，因Schema、事务和ON语义不兼容；可行方案仅有应用层拼接或联邦查询中间件，前者更稳定，后者适用低频报表场景。
SQL 和 NoSQL 数据源没法直接 JOIN
关系型数据库的 JOIN 依赖严格 Schema 和事务一致性，而 NoSQL（比如 MongoDB、Elasticsearch）通常没主键约束、没跨集合事务，更不支持标准 SQL 的 ON 语义。硬写 SELECT * FROM pg_table JOIN mongo_collection ON ... 会直接报错或被驱动拒绝。
常见错误现象：ERROR: relation "mongo_collection" does not exist（PostgreSQL 报错），或 JDBC 驱动抛出 SQLFeatureNotSupportedException。
真实可行路径只有两条：在应用层拼接，或用中间件做联邦查询。前者可控性强，后者省代码但引入新运维负担。
应用层聚合是最稳的落地方式
把 SQL 查询和 NoSQL 查询拆开，在业务代码里分别执行，再用内存做关联。关键不是“能不能”，而是“怎么避免性能崩盘”。
- 先查 SQL 主表（如
orders），拿到关键 ID 列表（order_id），**别一次性 SELECT *，只取后续关联需要的字段 - 把 ID 列表转成 NoSQL 可批量查的形式：MongoDB 用
$in，Elasticsearch 用termsquery，注意单次请求大小限制（比如 ES 默认http.max_content_length是 100MB） - 关联逻辑用哈希表（
Map<string object></string>）预存 NoSQL 结果，键为 ID；遍历 SQL 结果时直接map.get(orderId)，别嵌套循环 - 加缓存要谨慎：SQL 数据可能更新频繁，NoSQL 数据可能延迟写入，
cache.put("order_123", doc)前得想清楚失效策略
Federated Query 工具选型要看实际瓶颈
像 Apache Calcite、PrestoDB、Doris 确实能写跨源 SQL，但它们不是“魔法开关”。性能取决于底层 connector 实现质量，而不是语法多漂亮。
使用场景：报表类查询（低频、可容忍秒级延迟）、数据治理平台后台任务。不适合高并发交易链路。
- MongoDB connector 在 Presto 中不支持写操作，且
$lookup类聚合无法下推，全量拉到 Presto 内存再匹配，容易 OOM - PostgreSQL FDW（Foreign Data Wrapper）连 MySQL 没问题，连 MongoDB 需要第三方扩展（如
mongo_fdw），编译麻烦、版本兼容性差 - 如果 NoSQL 是 Elasticsearch，
es-sql或opensearch-sql插件只解决“ES 自己的 SQL 化”，不解决“和 PostgreSQL 联合查”
时间窗口对齐是隐性雷区
SQL 数据库里的 updated_at 和 NoSQL 里的 last_modified 字段，看起来一样，但时钟不同步、写入延迟、事务提交顺序差异，会导致“同一笔订单，SQL 查出来已支付，NoSQL 还显示待付款”。
参数差异：PostgreSQL 默认用 CLOCK_REALTIME，MongoDB 驱动默认用客户端本地时间生成 ObjectId 时间戳，Elasticsearch 写入时若没显式设 @timestamp，会用协调节点时间。
实操建议：
- 所有跨源关联查询，必须约定一个权威时间源（比如统一用 Kafka event timestamp 或中心化时间服务）
- 避免基于“最后更新时间”做增量同步，改用变更日志（PostgreSQL
logical replication+ MongoDBchange stream） - 前端展示时别渲染“混合状态”，宁可显示“数据同步中”，也别拼出矛盾结果
最麻烦的从来不是语法怎么写，而是两个系统之间那几百毫秒的延迟、一次未捕获的网络抖动、或者某个凌晨三点自动触发的分片重平衡。这些细节不写进日志，就永远在监控图表里藏得严严实实。
