为什么我的Sql Server查询计划在加入数据时使用扫描而不是搜索？

Question

从MySQL背景来看，我很难理解以下设置有什么问题。

我有两个表变量和维度

两者都有一个主键，变量还有一个名为dimension_instance_1_uid的维的外键，索引是创建

当我执行这样的查询时

SELECT
this_.name, dimensioni4_.name
FROM dbo.variable this_
INNER JOIN dbo.dimension_instance dimensioni4_
-- even with index hint nothing changes...
-- WITH (INDEX(PK_dimension_instance))
ON this_.dimension_instance_1_uid = dimensioni4_.UID

似乎索引未用于seek，并且根据执行计划执行scan。它显示两个索引扫描而不是一个索引扫描和一个索引搜索。

我希望索引寻找，因为在我dimension_instance的情况下，只有10条15k记录与variable表中的条目匹配。

任何人都可以解释我对MS SQL索引的工作方式的误解。

Answer 1

查询执行计划和查询优化器估计有关数据库内部数据和其他变量的更好操作是什么：在您的情况下，它可能认为执行索引扫描而不是查找的查询成本更低：这可能是由低行数引起的

Answer 2

  

当我查看执行计划时，似乎根本没有使用索引。

我是瞎了，你是瞎了还是你发错了执行计划？

该计划有两个源表，bot使用Clustered Index Scan。这是源表访问的索引的100％使用。

现在，为什么扫描而不是搜索，因为你没有任何限制（where子句），这可能是最快的方法。如果te机器假设两个表都必须完全读取，为什么要进行搜索而不是扫描？

Answer 3

  

任何人都可以解释我对MS SQL索引的工作方式的误解。

这不是你误解的索引，而是Hash Join。散列连接只是没有用于连接谓词的索引（与嵌套循环连接不同）。

http://use-the-index-luke.com/sql/join/hash-join-partial-objects