SQL Server索引怀疑

时间:2012-01-14 18:13:33

标签: sql indexing

索引用于提高sql查询的性能,但我总是发现很难决定在哪种情况下我应该使用索引而不是哪种情况。我想澄清一些关于非聚集索引的疑问

  1. 什么是非聚集索引键。正如书中所说,非聚集索引的每个索引行都包含非聚簇键值,因此它意味着它是我们创建非聚簇索引的列,即如果在empname varchar(50)上创建索引,那么非聚簇键将是 empname。

  2. 为什么最好在宽度较小的列上创建索引。这是由于与更多宽度列的比较需要更多的时间用于SQL服务器引擎,或者是因为它将增加中间节点的层次结构,因为页面大小是固定的,因此页面中的宽度列更多或者它将包含的节点更少的索引行。

  3. 如果一个表包含多个非聚类列,那么非聚簇键是否将是所有这一列的组合,或者某个唯一的id是由SQL在内部生成的定位符,它将指向实际的数据行。如果可能的话,请将其清除一些实时的示例和图表。

  4. 为什么说具有不可重复值的列有利于创建索引,即使它包含重复值,它肯定会提高性能,因为一旦达到某个键值,它的定位器将立即找到它的实际行。

  5. 如果索引中使用的列不是唯一的,它如何从表中查找实际数据行。

  6. 请参阅任何有助于消除疑虑的书籍或教程。

1 个答案:

答案 0 :(得分:0)

首先,我认为我们需要涵盖实际指数。通常在RDBMS索引中使用B-tree's的变体实现(B +变体是最常见的)。简而言之 - 想一个针对存储在磁盘上而优化的二叉搜索树。在B树中查找密钥的结果通常是表的主键。这意味着如果索引中的查找完成并且我们需要的数据多于索引中的数据,我们可以使用主键在表中进行搜索。

请记住,当我们考虑RDBMS的性能时,我们通常在磁盘访问中测量它(我决定忽略锁定和其他问题)而不是CPU时间。

索引是非聚集的意味着存储表中数据的实际方式与索引键无关 - 而聚簇索引指定表中的数据将被排序(或聚集) index key - 这就是为什么每个表只能有一个聚簇索引。

2)回到我们的测量性能模型 - 如果索引键的宽度很小(适合少量的字节),这意味着我们检索的每个磁盘数据块可以容纳更多的键 - 并且因此执行如果测量磁盘I / O,在B树中查找要快得多。

3)我尝试进一步解释这一点 - 不幸的是,我没有任何图表或图纸来表明这一点 - 希望其他人可以来并分享这些。

4)如果你正在运行这样的查询:

SELECT something, something_else FROM sometable t1 WHERE akey = 'some value'

在索引定义如下的表上:

CREATE INDEX idx_sometable_akey ON sometable(akey)

如果sometable有很多行,其中akey等于'some value',这意味着在索引和实际表中都有很多查找来检索something和something_else的值。然而,如果此过滤很可能返回少量行,那么它也意味着更少的磁盘访问。

5)见前面的解释

希望这会有所帮助:)

相关问题