Xai*_*oft 5 t-sql sql-server indexing
假设我有一个名为"table"的表,我有3列,a,b和c.
列a,b上有非聚集索引是什么意思？
列a,b上的非聚簇索引与列b上的非聚簇索引相同,是吗？(注意顺序).
另外,列a上的非聚簇索引是否与a上的非聚簇索引相同？
我正在查看网站的sqlserver性能,他们有这些dmv脚本,它会告诉你,如果你有重叠索引,我相信它是说a上的索引与a,b相同,所以它是多余的.对于索引这是真的吗？
最后一个问题是为什么聚集索引放在主键上.大多数情况下,不会查询主键,因此聚集索引不应位于查询最多的列上.我可能在这里遗漏了一些东西,比如在主键上加速连接？
很棒的解释.我应该将其转换为维基并更改标题索引说明吗？
Joe*_*orn 16
这将转变为索引的更一般性介绍,但我怀疑你仍然会发现它很有用.前两段特别提到你的问题.
这是指表格在磁盘上的物理排列方式.聚簇索引的工作原理是根据索引定义对磁盘上的表中的物理页面和行进行排序.非聚集索引使用磁盘上的单独位置来存储索引中的列的副本(并且仅存储那些列),以及指向源记录的指针.因此,聚簇索引通常更快,因为它们将始终覆盖查询中所需的任何数据.但是,您只能获得其中一个,否则您将复制整个表.同样重要的是要知道向表中添加非聚簇索引实际上会降低写入操作(如插入和更新)的速度,因为数据库必须重建索引,或至少重建索引中的某些页面.
在索引(A,B)是不一样的(B,A).如果是第一种情况,则索引中的记录按列排序A,而列B仅在您具有重复值时影响索引顺序A.B仅使用列值搜索索引对您没有帮助,因为您仍然必须扫描索引中的每个记录以查找所有匹配值B.在第二种情况下,会发生相反的情况:记录按列排序B,而列A只在有重复值时才有用A.A仅使用列值搜索该索引对您没有帮助.
有时,数据库可以完全从索引中满足查询的要求.在这种情况下,索引被称为该查询的"覆盖"索引.这是有利的,因为索引通常被缓存在内存中,因此数据库可能根本不必去做磁盘.要理解这一点,请设想一个关于(A,B)重复值非常少的索引A.包含A在索引中似乎很浪费,除非你有一个经常运行的查询,它查找特定的值A并且也需要B.此索引现在将节省大量工作返回到原始表以进行检索B.
选择性是从0到1的值(通常表示为百分比),它告诉您索引中每个值的唯一性.选择性为1或100%意味着没有重复.选择性为0表示列中只有一个值.通常,较高的选择性(接近1)对于指数更好.
为了证明这一点,请考虑低选择性指数会发生什么.例如,您尝试通过向具有10000条记录的表中的位列添加索引来加速查询.在这种情况下(假设均匀分布),选择性为.5.您运行查询,索引返回5000条记录.但是这些记录中的每一个仍然必须返回原始表,并且由于索引顺序与表顺序不匹配,因此必须对表进行大量单独的查找.相反,它可能更快地扫描整个表开始完成以检索所需的数据.
选择性解释了为什么要在主键上进行聚类.由于聚簇索引告诉数据库如何对表进行排序,因此选择低于100%的选项意味着查询必须更频繁地扫描表.主键上的聚类为您提供了完美的选择性.并且由于此主键通常用作其他索引中的记录指针,因此您希望将其保持尽可能小(即整数标识列).
这里有关于选择性和索引的好文章:http:
//www.akadia.com/services/ora_index_selectivity.html
这指的是数据库是否能够使用带索引的特定过滤器.
正如我们所示,索引通常首先将数据排序为特定顺序,因此查找到该索引可以使用一些有效的方法,如基于树的搜索而不是较慢的线性搜索.任何无法与排序数据进行有效比较的内容都不能与索引一起使用.一个很好的例子是LIKE运营商.这是可以接受的:
SELECT * FROM [Table] WHERE [Column] LIKE @Value + '%'
但这不是可以理解的:
SELECT * FROM [Table] WHERE [Column] LIKE '%' + @Value + '%'
可以使过滤器不可思议的其他一些东西是非确定性函数(并且有比你想象的更多的东西).
我见过的一个常见错误是为表中的每一列都有一个单独的索引.例如,有人会拿一个表列(A,B,C,D),并创建四个单独的索引,分别为A,B,C,D,相信他们现在已经收录每列等每个查询要快.实际上,由于我希望我已经解释过的原因,这很少有用,而且往往会使事情变得更糟而不是更好,因为数据库现在需要为数据的每次更改更新这些索引.