聚簇索引必须唯一吗？

如果聚集索引不是唯一的，会发生什么？因为插入的行流到某种“溢出”页面，会导致性能下降吗？

它是“独特的”吗？使其独特的最佳方法是什么？

我之所以问是因为我当前正在使用聚集索引将表划分为逻辑部分，但是性能如此一般，最近我得到了使聚集索引唯一的建议。我想要第二点意见。

谢谢！

他们不具有是唯一的，但可以肯定的是鼓励。
我还没有遇到过要在非唯一列上创建配置项的方案。

如果在非唯一列上创建配置项会怎样？

如果聚集索引不是唯一索引，则SQL Server通过添加一个内部生成的值（称为“唯一符”）使所有重复键成为唯一键

这会导致性能下降吗？

添加唯一符肯定会增加一些计算和存储开销。
这种开销是否显着取决于几个因素。

• 该表包含多少数据。
• 插入率是多少？
• 一次选择中使用CI的频率（当不存在覆盖索引时，几乎总是如此）。

正如Remus在评论中指出的那样进行编辑，确实存在一些使用案例，在这些案例中，创建非唯一的CI将是一个合理的选择。我没有遇到那种情况只是表明我自己缺乏接触或能力（选择您的选择）。

我想了解一下索引女王，金伯利·特里普（Kimberly Tripp）在这个话题上怎么说：

由于一些原因，我将从对群集密钥的建议开始。首先，这是一个容易做出的决定，其次，及早做出此决定有助于主动防止某些类型的分裂。如果可以防止某些类型的基表碎片，则可以最大程度地减少一些维护活动（要求在SQL Server 2000中进行某些维护，而在SQL Server 2005中进行较少的维护）要求表处于脱机状态。好的，我稍后再讨论。

让我们从我在集群密钥中寻找的关键事物开始：

* Unique
* Narrow
* Static

为什么独特？ 集群键应该是唯一的，因为集群键（如果存在）将用作所有非集群索引中的查找键。以书后的索引为例-如果您需要查找索引条目指向的数据-否则该条目（索引条目）必须唯一，否则，该索引条目将是您要查找的索引条目？因此，当您创建聚簇索引时-它必须是唯一的。但是，SQL Server不需要在唯一列上创建群集密钥。您可以在任何所需的列上创建它。在内部，如果群集密钥不是唯一的，则SQL Server将通过向数据添加4字节整数来“唯一化”它。因此，如果聚集索引是在非唯一的事物上创建的，那么不仅在创建索引时会产生额外的开销，还会浪费磁盘空间，

资料来源： 群集主题辩论不断增加-再次！

聚簇索引必须唯一吗？

他们没有，有时候，如果不是，那会更好。

考虑一个表，该表具有半随机，唯一的EmployeeId和每个员工的DepartmentId：如果select语句为

SELECT * FROM EmployeeTable WHERE DepartmentId=%DepartmentValue%

那么DepartmentId即使聚簇索引不是唯一索引（如果不是唯一索引），它也是对性能最好的选择（对性能最好，因为它可以确保给定DepartmentId中的所有记录都是聚簇的）。

你有参考吗？

有聚集索引设计指南例如，它说，

除少数例外，每个表都应在一个或多个列上定义一个聚集索引，该聚集索引提供以下内容：

• 可用于经常使用的查询。
• 提供高度的独特性。
• 可用于范围查询。

例如，我对“高度唯一性”的理解是，如果大多数查询都想选择给定城镇内的记录，那么选择“国家”作为聚集索引是不好的。