这个简单的SQL查询可以优化吗？

我有以下查询：

SELECT COUNT(*) 
FROM Address adr INNER JOIN 
     Audit a on adr.UniqueId = a.UniqueId

>在数据库上(130万个地址,超过400万次审计)
>两个UniqueId列都是群集主键

查询需要很长时间才能完成.我觉得愚蠢,但有没有办法优化它？我想计算所有具有基础可审计的地址条目.

编辑：非常感谢您的所有输入,这里有一些更多的细节：

>查询将不会经常运行(它仅用于验证),但感谢索引视图提示,我将确定添加到我的知识.
>所有地址都有一对一的审核.并非所有审核都是地址.
>查询需要1分钟以上才能完成.我觉得这太长了,不便于简单计算.

解决方法

由于您有两组数据,按相同的值排序..您是否尝试过合并连接而不是嵌套循环连接？

SET STATISTICS IO ON
SET STATISTICS TIME ON

SELECT COUNT(*)  
FROM Address adr INNER JOIN  
     Auditable a on adr.UniqueId = a.UniqueId 
OPTION (LOOP JOIN)

SELECT COUNT(*)  
FROM Address adr INNER JOIN  
     Auditable a on adr.UniqueId = a.UniqueId 
OPTION (MERGE JOIN)

SELECT COUNT(*)  
FROM Address adr INNER JOIN  
     Auditable a on adr.UniqueId = a.UniqueId 
OPTION (HASH JOIN)

编辑：

这些解释是概念性的. sql Server可能正在执行比我的示例所示更复杂的操作.这种概念性理解与SET STATISTICS命令对时间和逻辑IO的测量以及查询执行计划的检查相匹配 – 构成了我的查询优化技术(长达四年)的基础.愿它和你一样为你服务.

建立

>获得5副牌.
>取1个牌组并生成父数据集.
>取其他4个套牌并生成子数据集.
>按卡值对每个数据集进行排序.
>设m是父数据集中的卡数.
>设n为子数据集中的卡数.

nestedLoop

>从父数据集的顶部取出一张卡片.
>在子数据集中搜索(使用二分搜索)第一次出现匹配.
>在第一场比赛的子数据集中向前搜索,直到找到不匹配.你现在找到了所有的比赛.
>对父数据集中的每张卡重复此操作.

嵌套循环算法迭代父数据集,然后为每个父数据集搜索子数据集一次,使其成本为：m * log(n)

合并

>从父数据集的顶部取出一张卡片.
>从子数据集的顶部取出一张卡片.
>如果卡片匹配,从每个牌组的顶部拉出牌,直到找到不匹配的牌.在父匹配和子匹配之间生成每个匹配对.
>如果卡片不匹配,请在父卡和子卡之间找到较小的卡片,然后从该数据集的顶部取出卡片.

合并连接算法迭代父数据集一次,子数据集迭代一次,使其成本为：m n.它依赖于订购的数据.如果您要求对未订购的数据进行合并连接,则需要进行订购操作！这使得成本为(m * log(m))(n * log(n))m n.在某些情况下,甚至可能比嵌套循环更好.

哈希

>拿一张牌桌.
>从父数据集中取出每张卡,并将其放在卡片表中,您可以在其中找到它(不必与卡片值有任何关系,只需要方便您).
>从子数据集中取出每张卡片,在纸板桌子上找到匹配的父卡片并生成匹配对.

散列连接算法迭代父数据集一次,使其成本为：m n.它依赖于拥有足够大的卡表来保存父数据集的全部内容.

原文地址：https://www.jb51.cc/mssql/77840.html