如果聚集索引不是唯一的,会发生什么?因为插入的行流到某种“溢出”页面,会导致性能下降吗?
它是“独特的”吗?使其独特的最佳方法是什么?
我之所以问是因为我当前正在使用聚集索引将表划分为逻辑部分,但是性能如此一般,最近我得到了使聚集索引唯一的建议。我想要第二点意见。
谢谢!
Answers:
他们不具有是唯一的,但可以肯定的是鼓励。
我还没有遇到过要在非唯一列上创建配置项的方案。
如果在非唯一列上创建配置项会怎样?
如果聚集索引不是唯一索引,则SQL Server通过添加一个内部生成的值(称为“唯一符”)使所有重复键成为唯一键
这会导致性能下降吗?
添加唯一符肯定会增加一些计算和存储开销。
这种开销是否显着取决于几个因素。
正如Remus在评论中指出的那样进行编辑,确实存在一些使用案例,在这些案例中,创建非唯一的CI将是一个合理的选择。我没有遇到那种情况只是表明我自己缺乏接触或能力(选择您的选择)。
我想了解一下索引女王,金伯利·特里普(Kimberly Tripp)在这个话题上怎么说:
由于一些原因,我将从对群集密钥的建议开始。首先,这是一个容易做出的决定,其次,及早做出此决定有助于主动防止某些类型的分裂。如果可以防止某些类型的基表碎片,则可以最大程度地减少一些维护活动(要求在SQL Server 2000中进行某些维护,而在SQL Server 2005中进行较少的维护)要求表处于脱机状态。好的,我稍后再讨论。
让我们从我在集群密钥中寻找的关键事物开始:
* Unique
* Narrow
* Static
为什么独特? 集群键应该是唯一的,因为集群键(如果存在)将用作所有非集群索引中的查找键。以书后的索引为例-如果您需要查找索引条目指向的数据-否则该条目(索引条目)必须唯一,否则,该索引条目将是您要查找的索引条目?因此,当您创建聚簇索引时-它必须是唯一的。但是,SQL Server不需要在唯一列上创建群集密钥。您可以在任何所需的列上创建它。在内部,如果群集密钥不是唯一的,则SQL Server将通过向数据添加4字节整数来“唯一化”它。因此,如果聚集索引是在非唯一的事物上创建的,那么不仅在创建索引时会产生额外的开销,还会浪费磁盘空间,
资料来源: 群集主题辩论不断增加-再次!
newsequentialid()
来获得几乎是序列化的GUID。但是可以:如果您添加自己的唯一ID(我总是更喜欢INT IDENTITY),那么您手头就有该值,就可以使用它(例如,建立FK关系)。SQL Server添加的独特性对您不可见,因此它们只是您无法利用的开销。
聚簇索引必须唯一吗?
他们没有,有时候,如果不是,那会更好。
考虑一个表,该表具有半随机,唯一的EmployeeId和每个员工的DepartmentId:如果select语句为
SELECT * FROM EmployeeTable WHERE DepartmentId=%DepartmentValue%
那么DepartmentId
即使聚簇索引不是唯一索引(如果不是唯一索引),它也是对性能最好的选择(对性能最好,因为它可以确保给定DepartmentId中的所有记录都是聚簇的)。
你有参考吗?
有聚集索引设计指南例如,它说,
除少数例外,每个表都应在一个或多个列上定义一个聚集索引,该聚集索引提供以下内容:
- 可用于经常使用的查询。
- 提供高度的独特性。
- 可用于范围查询。
例如,我对“高度唯一性”的理解是,如果大多数查询都想选择给定城镇内的记录,那么选择“国家”作为聚集索引是不好的。