sql-server – 数据库表何时变得足够大以至于索引是有益的？

假设在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性能,但这是另一个故事.

猜你在找的MsSQL相关文章