SQL Server索引怀疑

Question

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

1. 什么是非聚集索引键。 如书所述，非聚集索引的每个索引行都包含非聚集键值，所以这意味着它是我们在其中创建非聚集索引的列，即如果在empname varchar（50）上创建索引，则非聚集键将是该empname。

2. 为什么最好在宽度较小的列上创建索引。 这是由于与更多宽度的列进行比较会导致SQL Server引擎花费更多时间，或者是由于页面大小固定时，它将增加中间节点的层次结构，因此页面所包含的宽度更大的列或节点所包含的索引行会更少。

3. 如果一个表包含多个非聚集列，那么SQL将使用定位器在内部生成指向实际数据行的非聚集键是该列的组合，还是某个唯一ID。 如果可能，请清除它，将提供一些实时示例和图形。

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

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

请参阅任何有助于消除我的疑问的书或教程。

Answer 1

首先，我认为我们需要涵盖实际的索引。 通常在RDBMS中，索引是使用B树的变体（最常见的是B +变体）来实现。 简而言之-考虑针对存储在磁盘上而优化的二进制搜索树。 在B树中查找键的结果通常是表的主键。 这意味着，如果索引中的查找完成并且我们需要的数据多于索引中存在的数据，则可以使用主键在表中进行查找。

请记住，当我们考虑RDBMS的性能时，通常会通过磁盘访问（我决定在这里忽略锁定和其他问题）来衡量性能，而不用太多的CPU时间。

非聚集索引意味着表中数据的实际存储方式与索引键无关-聚集索引指定表中的数据将按索引键排序（或由索引键聚集）-这就是为什么每个表只能有一个聚集索引的原因。

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）参见前面的解释

希望这可以帮助 ：）