一条 SQL 语句 你的所有数据库.
您的订单数据存储在 MySQL 数据库中，您的客户数据存储在 PostgreSQL 数据库中，而大家争论不休的目标数据则存储在总部的一台 SQL Server 服务器上。 联合查询 让你写一个普通的 选择 它会同时读取这三个文件，并返回一个单独的表格——没有导出，没有复制到任何地方，也不会在防火墙上打开任何新文件。
On every plan, including Free · Free runs 2 sources and 250 result rows — the ceilings grow with your tier
38 数据库连接器——可以跨越任意两个连接器进行连接，组合方式不限
与它们一起出现在查询流中： 8 使用相同的 SQL 查询 API 连接器
53 总共有 1000 个数据源。您的 API 连接器像其他所有组件一样使用 SQL 进行查询——并且联合语句连接您的 1000 个数据源。 数据库 联系。 请参阅 API 连接器
将连接名称放在表格前面。
这是本页唯一的新概念。下面每个高亮显示的名称都代表一个不同的数据库，位于不同的位置，由不同的网络代理访问——但它们仍然属于同一个查询。
——一个联合查询 · 没有复制任何内容
选择 c.区域，
COUNT(*) AS 订单，
总计(o.total) AS 收入，t.target
从 mysql_prod.shop.orders1 o
连接 pg_crm.public.customers2 c 关于 c.id = o.customer_id
连接 mssql_erp.dbo.region_targets3 t 关于 t.region = c.region
地点 o.placed_at >= 日期 '2026-07-01'
GROUP BY c.区域，t.目标
ORDER BY 收入 DESC;mysql_prod, pg_crm 和 mssql_erp 这些只是你给自己的关系起的名字——这三个部分是 连接、模式、表这就是人们所说的 联合数据库三个独立的数据库回答同一个问题，数据既不合并也不移动。示例架构；您的表结构将与您的实际表结构相同。
每个名称的解析位置
mysql_prod
MySQL · shop.orders
云代理
筛选到七月份的数据，然后在发送任何商品之前计算每位客户的总收入。
pg_crm
PostgreSQL · public.customers
区域代理
仅返回 id 和 region 列——查询名称中仅有的两列。
mssql_erp
SQL Server · dbo.region_targets
总公司代理
按区域交付目标，以 T-SQL 编写，因此可以原生运行。
三个代理人，三个网络，一份声明——但他们中没有一个人打开端口来发布这份声明。
覆盖面更广，而非曝光度更高
同时读取两个数据库与读取一个数据库使用的路径完全相同。获取过程不会打开任何新的资源。
仅限出站
代理程序会打开一个加密连接到查询流，并通过该连接传输请求和结果。无需更改入站端口、VPN 或防火墙设置——您的凭据永远不会离开您的网络。
只读，每一段
查询语句的每一部分在执行到任何位置之前都会经过检查： 选择, 和 和 解释 仅此而已。联合查询无法写入任何数据库，任何被拒绝的数据都永远不会到达这些数据库。
它无法控制你的服务器
对于单个数据库，单次查询所能传输的数据量存在上限，代理程序一旦达到上限就会停止运行。 地点 这条条款只会让你收到一条错误信息，而不是浪费一个下午的时间。
三个步骤，但没有一个步骤是数据管道。
选择你的连接
选择团队已建立的两个或多个连接。至少需要两个连接——这才能实现联合查询。不会复制任何内容，也不会创建新密码。
请写一个陈述
将每个表格命名为 连接模式表然后编写普通的 SQL 语句。运行之前，您可以查看执行计划：了解要向哪个数据库查询什么内容。或者，您可以描述查询请求，让 Nova 生成执行计划。
像保存其他查询一样保存它
一旦成功运行，它就会被保存下来——因此可以共享、添加筛选条件、作为每周报告发送、发布为 API 端点或导入到电子表格中。
每个数据库都承担着自己一部分工作。
连接两个数据库最简便的方法是把两个表都拖过网络，然后再进行整理。这种方法速度很慢，而且意味着要传输的数据量远远超过实际需要的数据量。
所以我们反其道而行之。筛选、选择列和统计总数等操作都由其他人负责。 返回到每个数据库自行执行操作用它自己的语言。一份汇总了数百万行数据的报告会返回以下内容： 少量分组总数 ——而不是他们身后的数百万排人。
剩下的东西，我们都会做——然后我们会告诉你哪个是哪个。 跨数据库连接是我们的工作，因为每个数据库之间都无法直接访问其他数据库。执行计划详细列出了每个数据库的请求内容以及我们最终完成的操作，因此任何耗时的查询都会一目了然。 前 你来运行它。
它宁愿拒绝承认错误，也不愿默默地犯错。
合并独立数据库的一个尴尬之处在于：它们的结果并非总是完全一致。即使面对同一个问题，两个数据库给出的答案也可能在小数点后最后一位、对“相等”的定义，甚至“前十位”的含义上有所不同。
如果你是新手，以下是简短版本： 数据库并非仅仅是一堆数据行的集合。它对如何计算金额、如何对单词进行排序以及空值应该如何处理都有自己的一套规则。如果让两个不同的数据库对同一份客户名单进行排序，你可能会得到两个截然不同的结果——这并非因为其中一个数据库存在缺陷，而是因为它们的构建规则不同。任何用于连接数据库的工具都必须处理这个问题。大多数工具会默默地选择一个答案，然后祈祷一切顺利。但我们不会这样做。
我们采取的另一种做法只有两种结果， 查询生成器会显示你得到的是哪一个：一个计划标签，在你输入时显示“准备就绪”或“已拒绝”，以及一个包含完整工作过程的计划选项卡。
当分歧在于 如何 计算完成后，我们不再要求您的数据库执行该部分操作，而是在拼接步骤中完成，因为拼接步骤有一套统一的规则。这会略微降低速度，但不会影响准确性，也无需您投入任何精力——您无需做任何事情。
- 金钱与精准。 当总数较大时，数据库中小数点后的位数调整和舍入方式可能不同。如果源端汇总和集中汇总的舍入方式存在差异，我们会将数据调回服务器并重新汇总。
- 文本排序。 无论
a位于之前B口音的比较方式，以及口音的区分，都是数据库层面的设置。依赖于此的比较结果由中央统一处理，不会下放到其他数据库。 - 排名和累计总分。 窗口函数（行号、累计总数、“每个区域的前 3 名”）总是在数据到达后计算，因为没有一个数据源可以看到其他数据源。
继续下去会改变什么 哪些行 返回结果——不仅仅是速度——因为没有安全的方法可以猜测。所以查询不会运行，并且消息会指出你自身 SQL 语句中的确切表达式和数据库，以便你知道需要修改什么。
- 源程序无法执行的功能。 如果您的过滤器使用了我们无法用该数据库方言准确表达的内容，那么唯一的替代方案是发送比您编写的查询范围更广的查询，或者创建一个等效的查询。这两种方法都是错误的，因此我们拒绝。
- 行限制在图形内部。 A
限制或顶部在连接之前，先对一个数据源应用该操作，返回任意数量的行，然后将这些行连接起来——得到一个看似合理但实际上毫无意义的表。限制条件属于最终结果。 - 改变了目标。 如果查询计划制定后连接被重新指向了不同的数据库，则存储的计划已过时，我们需要重新制定计划，而不是使用昨天的计划来处理今天的数据。
三次拒绝，以及每一次拒绝所蕴含的意义
无法推送 LOWER(c.email_domain) = ? 下推至 mssql_erp：函数不在下推允许列表中。
换句话说： 您的筛选器将一列包装在一个函数中，但来源无法保证会以与我们相同的方式应用该函数，因此我们无法保证它返回相同的行。 该怎么办： 改用普通列进行比较，或者将该条件移到源之外——消息会告诉您要查看哪个源。
限100 不能在连接之前应用于单个源：结果将是 100 行任意数据，而不是您答案的前 100 行。
换句话说： 只有当所有数据合并整理完毕后，“前100名”才有意义。 该怎么办： 保留语句整体的限制，这样它就能达到你预期的效果。
源 2 现在指向的连接或数据库与计划此查询时所指向的连接或数据库不同。
换句话说： 有人改变了什么 pg_crm 指。 该怎么办： 在查询生成器中打开它并重新规划——只需单击一下，即可在运行之前查看新计划。
这一切背后的原则是： 如果查询结果返回 错误的我们拒绝。如果它只是回来就好了。 缓慢地我们会进行测试并向您发出警告。我们绝不会为了您而牺牲数据质量。
你也不必独自应对拒绝的情况。 Nova 就坐在查询构建器编辑器旁边，对整个系统了如指掌：你提出问题，它会用通俗易懂的语言解释拒绝的原因，重写语句使其能够运行，并为你检查新的执行计划。如果你完全不想编写 SQL，只需描述问题，Nova 就会自动生成联合语句。
如果您更注重细节而非仅仅寻求保证，那么“查询构建器”的“计划”选项卡列出了所有数据源、实际发送的查询语句、它自动应用了哪些条件，以及我们集中完成的哪些部分。决策过程完全透明——包括我们选择更慢但更稳妥方案的部分。
联合查询就是一种查询
它并非一个拥有独立规则的独立产品。一旦保存，查询流的所有其他部分都会像处理您编写的其他任何内容一样处理它。
查询生成器
在同一编辑器中编写，并在旁边显示相同的模式树。“计划”选项卡显示每个数据库的请求内容；“分析”选项卡以图表形式显示每个数据库的性能表现。
新星人工智能
用英文描述问题，Nova 会读取你的数据库模式并生成语句——包括每个表所属的连接。它还可以运行语句并绘制结果图表。
谷歌工作表
在插件中选择已保存的查询，合并后的结果就会显示在单元格中，格式正确且可刷新——就像任何单数据库查询一样。
在 Excel
Excel 中也是如此：可以运行单个或整个工作表，冻结标题、筛选器和就地更新功能，而不会影响您自己的公式列。
数据库 REST API
将跨数据库结果发布为带有键的 JSON 端点，这样任何使用它的人都不需要知道它来自三个系统。
人工智能助手的 MCP
Claude 和其他助手可以通过 MCP 列出并运行您的联合查询，因此可以在聊天中回答“上周每个地区的情况如何”之类的问题。
报告和警报
将其添加到日程中，汇总数据将通过 Slack、Google Chat、Discord、Telegram 或电子邮件发送给您——或者设置一个阈值，仅在数据发生变化时才通知您。
自动化与共享
按计划将结果同步到电子表格中，或者与同事共享查询，同事只能看到筛选器和“运行”按钮，永远看不到您的 SQL 或连接。
以前生成的报告包含两个导出函数和一个 VLOOKUP 函数。
几乎没有人只使用一个数据库。通常会有ERP系统、门店系统、CRM系统，以及上次收购后使用的各种系统。
这里下订单，那里有顾客
商店将订单写入 MySQL 数据库；CRM 系统则将客户和地区信息保存在 PostgreSQL 数据库中。“按地区划分的收入”不再需要两次导出和一个查找操作，而是简化为一个任何人都可以重新运行的已保存查询。
收购之后
两家公司，两套系统，一份董事会资料包周五到期。第一天就能看到合并后的版本，而真正的迁移工作则需要像往常一样耗时十八个月。
股票与卖出价之比
库存信息存储在另一个国家的仓库系统中；销售数据则存储在店铺数据库中。一份报表即可将两者并列呈现——而且这份报表每周一都会以报告的形式发送给您。
每个站点一个数据库，一个编号
每个国家、每个租户或每个店铺楼层都部署相同的模式。只需一条语句即可将它们相加，而无需维护一个运行查询五次并手动汇总的脚本。
联邦数据库、数据联邦、数据虚拟化
这三个名称指代的是相互重叠的概念，而大量的营销活动模糊了它们之间的界限。以下是每个名称的含义，以及我们实际从事的工作。
联邦数据库
A 联合数据库 （或联邦数据库系统）使多个独立的数据库像一个数据库一样运行，而无需将它们合并。每个数据库都拥有自己的存储空间、引擎和所有者；其上层接收查询并确定由哪个数据库来处理哪个部分。
查询流就是这一层。底层没有新的数据库，也没有数据被复制到新数据库中。
数据联邦
数据联邦 关键在于方法本身：将数据保留在原处，需要时再进行查询，而不是先将所有数据提取到中央副本中。另一种方法是使用数据管道和数据仓库——一夜之间将所有数据迁移过去，然后只查询中央副本。
两者都合理。当问题涉及多个系统、数据必须固定存储，或者数据仓库项目的成本超过其价值时，联邦模式更胜一筹。而对于涉及海量数据的繁重历史分析，数据仓库仍然是最佳选择。
数据虚拟化
数据虚拟化 是基于联邦的大型企业级产品——通常是联邦查询加上建模层、缓存和治理工具，作为一个独立的平台进行销售。
我们刻意选择成为其中那一小部分诚实的人： 对现有连接进行联合查询就在你们团队已经用来编写查询的工具里。无需建模项目，无需运行自己的服务器，也无需顾问。
联合查询常见问题解答
什么是联合查询？
联合查询是指一条 SQL 语句从多个独立的数据库读取数据，并返回一个合并后的结果。它不会先复制任何数据：语句会被拆分成针对每个数据库的多个小型查询，每个查询负责处理其能够处理的部分，然后将这些部分合并成最终结果。在查询流中，只要语句引用了两个或多个连接，它就自动成为联合查询。
我的数据库必须放在同一个地方吗？
不。它们可以位于不同的办公室、不同的云账户、不同的国家/地区，或者三者兼而有之——一个在服务器机房，一个在私有云网络中，一个在仓库的机器上。每个位置都运行一个网络代理，每个代理通过拨号连接到查询流。就您的防火墙而言，这只是一个普通的出站连接，因此无需开放任何内容，也无需构建 VPN。
您还可以将一台服务器上的多个数据库指向同一个代理；通常情况下，每个位置使用一个代理，而不是每个数据库使用一个代理。
我还需要数据仓库或 ETL 管道吗？
不适用于这种情况。无需加载任何数据，也无需维护任何计划——查询会在您运行的当下读取您的实时数据库，因此答案不会像昨晚的副本那样过时。联合查询无法取代的是对海量数据进行繁重的历史分析；这仍然是数据仓库的工作。一个简单的测试：如果查询跨越多个系统且需要保持最新状态，则使用联合查询。
我可以将哪些数据库连接起来？
您的任何数据库连接，无论组合如何：SQL Server、PostgreSQL、MySQL、MariaDB、Oracle、Snowflake、BigQuery、SQLite、Access 和 DuckDB。每个数据库都使用其自身的方言进行请求，因此同一条语句可能会发送不同的请求。 顶部 到 SQL Server 和 限制 无需您操心，即可迁移到 PostgreSQL。
不同的数据库在计算能力、排序和舍入方式上确实存在差异，因此并非每个表达式的每种组合都能得到精确答案。遇到这种情况时，你会收到一条包含表达式名称的具体消息，而不是一个近似正确的数字。
比查询单个数据库慢吗？
这取决于每个数据库能够自行完成多少工作——这正是我们优化的目标，也是执行计划所展示的内容。当所有过滤和分组操作都在数据库内部完成时，数据移动量极少，感觉就像执行一个普通的查询。当需要我们来完成一个大型连接操作时，数据移动量就会增加，执行计划会在查询运行前就明确显示这一点。此外，每个数据库的每次查询都有数据量上限，因此一旦出现错误，查询就会及时停止，避免持续运行。
将一个查询指向多个生产数据库是否安全？
它使用与您在此处运行的所有其他查询相同的安全模型。每个数据段都通过您自己的网络代理，经由一个加密的出站连接传输——无需入站端口、VPN 或防火墙更改——您的数据库凭据永远不会离开您的网络。每个数据段都以只读方式进行检查（选择, 和, 解释），联合查询不能写入任何地方，每个数据库只会看到一个查询访问你指定的列。
这与Trino、Presto或Denodo有何不同？
这与 Trino 和 Presto 推广的理念相同：一条 SQL 语句，即可推送至多个数据源。区别在于运行和学习的内容。Trino 和 Presto 需要部署、调优集群并将其连接到您的网络；数据虚拟化平台则在此基础上增加了一个建模层，并需要相应的许可证。而我们的产品则将相同的功能集成到您团队已使用的查询工具中，直接访问您已建立的连接，无需您自行运行任何服务器。
另一个区别在于我们会拒绝。如果数据库之间的结果不一致，可能会改变最终数据，我们会停止操作，并指出我们无法处理的表达式，而不是返回一个看似合理的结果。
我该如何处理这个结果？
您可以对任何已保存的查询执行所有操作，因为它本质上就是一个查询。您可以保存它、与团队共享、添加筛选条件、将其作为报告发送到 Slack 或电子邮件、将其发布为 REST 端点，或者将结果导入 Excel 和 Google Sheets。如果您更愿意描述问题而不是编写连接语句，Nova 还可以读取您的模式并自动生成语句。
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish