1

这吓坏了我，我不能再测试三天，所以我不妨问问......

假设一个标准的 JOIN 语句是这样的：

SELECT 
  names.name
  ,adresses.adress
FROM
  names
JOIN
  adresses
ON
  names.ID=adresses.FK_ID

假设您希望数据库引擎/优化器快速运行。

问题：有什么区别

  • 查询运行时间
  • 内存使用情况
  • 可用的 SQL Server 软件技术来提高运行时间

如果这些情况适用：

  1. 这两个表位于同一个数据库中
  2. 这两个表位于同一实例的两个不同数据库中
  3. 表“名称”位于我的实例中，表“地址”位于链接数据库（服务器对象）中

在案例 1 中，我增强此类查询运行时的常用策略（除了清除无效数据/重复项和减少必要的数据类型长度）是构建适当的索引和统计信息。

如果我在案例 2 中这样做，优化器是否能够像案例 1 一样利用索引和统计信息？查询计划看起来是否相似？运行时间和内存使用是否相似？（我几乎 100% 肯定它会，也读过这个：在两个不同数据库中的两个表之间连接有什么问题？）

在案例 3 中，显然会涉及耗时的网络流量和协议内容/握手。我的实例是否会先将完整的“地址”结果集加载到 RAM/swap 中，然后再进行 JOIN？或者它是否足够聪明地告诉链接服务器：“嘿，查找这些 ID 并将结果地址还给我！” ? （假设链接数据库中的“地址”在 FK_ID 上有一个索引）

假设“地址”在我的实例中，“名称”在链接的实例中，我会添加

WHERE names.name='John Smith'

对于查询，我的实例是否会加载一整套“名称”，然后在该堆中扫描匹配的 ID，然后在“地址”中进行索引查找？或者它是否能够询问链接的数据库：“你能为我找到这个名字的匹配 ID 吗？” （再次：假设存在一个关于 ID 的索引）然后用那个去它的“地址”？

基本上我想知道优化器到底有多聪明（我知道：它比我更聪明^^）以及两个优化器是否可以以聪明的方式合作并提出一个融合的查询计划或其他东西，至少在一个基本水平。

这个问题可能已经被处理/回答/写了很多次了。感谢您的指针/链接/答案/技巧/解决方法...

4

1 回答 1

2

简短的回答（考虑到您的问题的长度，我感到有点内疚）是优化器非常了解服务器上的信息（因此案例 1 和案例 2 应该有相同的计划），但不是那么聪明关于对方的信息。如果您对链接服务器（如 server.database.schema.table）执行 JOIN，您可能会以表扫描结束。

于 2013-10-05T02:05:08.467 回答