这个简单的SQL查询可以优化吗?
我有以下查询:
SELECT COUNT(*) FROM Address adr INNER JOIN Audit a on adr.UniqueId = a.UniqueId >在数据库上(130万个地址,超过400万次审计) 查询需要很长时间才能完成.我觉得愚蠢,但有没有办法优化它?我想计算所有具有基础可审计的地址条目. 编辑:非常感谢您的所有输入,这里有一些更多的细节: >查询将不会经常运行(它仅用于验证),但感谢索引视图提示,我将确定添加到我的知识. 解决方法由于您有两组数据,按相同的值排序..您是否尝试过合并连接而不是嵌套循环连接?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副牌. NestedLoop >从父数据集的顶部取出一张卡片. 嵌套循环算法迭代父数据集,然后为每个父数据集搜索子数据集一次,使其成本为:m * log(n) 合并 >从父数据集的顶部取出一张卡片. 合并连接算法迭代父数据集一次,子数据集迭代一次,使其成本为:m n.它依赖于订购的数据.如果您要求对未订购的数据进行合并连接,则需要进行订购操作!这使得成本为(m * log(m))(n * log(n))m n.在某些情况下,甚至可能比嵌套循环更好. 哈希 >拿一张牌桌. 散列连接算法迭代父数据集一次,使其成本为:m n.它依赖于拥有足够大的卡表来保存父数据集的全部内容. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |