假设在sql Server数据库中,如果我有一个包含两个int字段(比如说多对多关系)的表,它参与另外两个表之间的连接,那么表的大小足以在表中获得足够大的性能优势两个int字段的索引是否克服了所述索引带来的开销？
不同版本的sql Server之间的架构是否存在差异,从而大大改变了这个答案？
解决方法
对于涉及表行的一小部分的查询,索引总是有益的,有100行或1,000,000.
像这样的查询：
SELECT * FROM table1 t1 JOIN table2 t2 ON t2.col = t1.col
很可能会使用HASH JOIN.将构建较小表的哈希表,较大表中的行将用于探测哈希表.
为此,不需要索引.
但是,这个查询：
SELECT * FROM table1 t1 JOIN table2 t2 ON t2.col = t1.col WHERE t1.othercol = @value
将使用NESTED LOOPS：将使用table1.othercol上的索引搜索外部表(table1)中的行,并使用table2.col上的索引搜索内部表(table2)中的行.
如果你没有col1的索引,将使用HASH JOIN,它需要扫描两个表中的所有行和一些更多的资源来构建一个哈希表.
索引对于这样的查询也很有用：
SELECT t2.col FROM table1 t1 JOIN table2 t2 ON t2.col = t1.col
,在这种情况下,引擎根本不需要读取table2本身：您可以在索引中找到此查询所需的内容,该索引可以比表本身小得多,并且读取效率更高.
当然,如果您需要对数据进行排序并在table1.col和table2.col上都有索引,那么以下查询：
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
ORDER BY
t2.col
可能会使用MERGE JOIN方法,如果两个输入行集都已排序,并且其输出也已排序,这超快,这意味着ORDER BY是免费的.
请注意,即使您没有索引,优化器也可以选择Eager Spool您的小表,这意味着在查询持续时间内构建临时索引并在查询完成后删除索引.
如果查询很小,它会非常快,但同样,索引也不会受到影响(对于SELECT查询我的意思).如果优化器不需要它,则不会使用它.
但请注意,创建索引可能会影响DML性能,但这是另一个故事.
