聚集指数

Cha*_*aru 2 database sql-server indexing performance database-indexes

SQL Server中的Insert/Update/Delete语句应使用哪种类型的索引(clustered/nonclustrered).我知道它会产生额外的开销,但与非聚集索引相比,它的性能是否更好?另外哪个索引应该用于SQL Server中的Select语句?

mar*_*c_s 7

并非100%确定您期望听到的内容 - 您只能在表上拥有单个群集索引,并且默认情况下,每个表(边缘大小写异常很少)都应该有一个.所有索引通常都会帮助你的SELECT最多,有些往往会伤害INSERT,DELETE和可能的UPDATE(或者很多,如果选择不当).

对于每个操作,聚簇索引使表更快.是!确实如此.请参阅Kim Tripp的优秀The Clustered Index辩论继续获取背景信息.她还提到了她对聚集索引的主要标准:

  • 狭窄
  • 静态(永不改变)
  • 独特
  • 如果可能的话:不断增加

INT IDENTITY完美地实现了这一点 - GUID不会.有关详细背景信息,请参阅GUID作为主键.

为何缩小?因为聚簇键被添加到同一个表上的每个非聚集索引的每个索引页面(为了能够实际查找数据行,如果需要).您不希望在群集密钥中使用VARCHAR(200)....

为什么独特?请参阅上文 - 聚类键是SQL Server用于唯一查找数据行的项和机制.它必须是独一无二的.如果您选择一个非唯一的群集键,SQL Server本身将为您的键添加一个4字节的唯一键.小心那个!

下一篇:非聚集索引.基本上有一条规则:引用另一个表的子表中的任何外键都应该被索引,它将加速JOIN和其他操作.

此外,任何具有WHERE子句的查询都是一个很好的候选者 - 首先选择那些执行很多的子句.在ORDER BY语句中将索引放在WHERE子句中显示的列上.

下一步:测量您的系统,检查DMV(动态管理视图)以获取有关未使用或缺失索引的提示,并反复调整您的系统.这是一个持续的过程,你永远不会完成!

另一个警告:使用大量的索引,您可以使任何SELECT查询真的非常快.但与此同时,必须更新所有相关索引的INSERT,UPDATE和DELETE可能会受到影响.如果你只选择SELECT - 坚果!否则,这是一个精细而微妙的平衡行为.您可以随时调整单个查询 - 但系统的其余部分可能会受此影响.不要过度索引数据库!放置一些好的索引,检查并观察系统的行为,然后再添加一两个,然后再次:观察整体系统性能如何受到影响.