JET SQL性能/ SQL理解

Question

这不是一个需要回答的问题，更多的是一个关于为什么会发生这种情况的疑问。

我在一个表中有一个用'Y‘或'N’填充的字段，并且我有一个查询，该查询简单地获取该字段的值并弹出到另一个表中

该表中大约有25,000条记录

下面的查询大约需要25秒才能运行

UPDATE ObjectivesApproved 
       INNER JOIN Approved 
          ON ObjectivesApproved.ID = Approved.ID 
   SET ObjectivesApproved.Football = [Approved].[Cri Football Related];

删除联接操作会使查询花费更长的时间。

但是，如果我执行以下操作，则整个操作所需的时间不到5秒，即使它正在执行2个查询

UPDATE ObjectivesApproved 
       INNER JOIN Approved 
          ON ObjectivesApproved.ID = Approved.ID 
   SET ObjectivesApproved.Football = 'Y' 
 WHERE (([Approved].[Cri Football Related]='Y'));

UPDATE Approved 
       INNER JOIN ObjectivesApproved 
          ON Approved.ID = ObjectivesApproved.ID 
   SET ObjectivesApproved.Football = 'N' 
 WHERE (([ObjectivesApproved].[Football] Is Null));

我对我的变通方法很满意，即使它有点不雅，但为了加深我对SQL的理解，为什么会发生这种情况？

Answer 1

您的第一个版本无论如何都要更新25K行，但是它必须保持表的同步，因为它是在逐行的基础上使用从一个表到另一个表的值。更新的每一行都必须从一个字段中读取- 25K次。

您的第二个版本(两个语句)过滤数据，而不是逐行比较。在内部，找到一组记录，然后批量更新，而不是逐行计算。值'Y‘不必每次都查找-它是常量。

想象一下，如果我要求你根据我给你的列表给25K的盒子涂上黑色或白色。拿起第一个框，检查列表，给它上色，拿起第二个框，检查列表，给它上色，重复是不是更快。还是把所有应该是白色的拿出来给它们上色，然后把所有黑色的拿出来给它们上色，这样会更快。注意:在第二种情况下，你只需要“检查列表”2次，而第一种情况是25K次。

Answer 2

我把这些放在评论中，但我意识到它们构成了某种程度上的答案：

您说没有索引，但是您说ID字段是PKs。如果是这样的话，这些字段必须有一个唯一的索引。如果没有，那么它们就不是真正的PKs，这可能解释了为什么带有WHERE子句的版本比只有JOIN的版本更快。

此外，谷歌"Jet SHOWPLAN“，这样你就可以看到Jet查询优化器正在做什么，然后你就可以真正看到发生了什么。

有了索引，你会得到一个索引合并，这应该是相当快的。如果没有他们，我不确定Jet会怎么做。此外，如果您的Y/N字段被编入索引，则可能会有所不同。建议不要索引稀疏填充字段(即基数较低的字段)的powers，但我发现Jet/ACE中的索引布尔型字段实际上可以产生显著的性能差异。