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

不同版本的SQL Server之间的架构是否存在差异,从而大大改变了这个答案？

解决方法

有关计划和性能详细信息的示例,请参阅我的博客中的此条目：

> Indexing tiny tables

像这样的查询：

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!