问题标签 [clustered-index]

SQL 2000
NED 表有一个外键到 SIGN 表 NED.RowID 到 SIGN.RowID
SIGN 表有一个外键到 NED 表 SIGN.SignID 到 NED.SignID
RowID 和 SignID 是集群主键，它们是 GUID (不是我的选择）
WHERE 子句是：

为什么这个查询的 SIGN 表上有一个 INDEX SCAN？什么会导致对聚集索引进行索引扫描？谢谢

当我尝试使用 NDB 存储引擎创建表时，出现以下错误：

如何改变这个变量的大小？我不知道它是在哪里存储或设置的。

我对 DB 的了解有限，仅将 DB 用作应用程序程序员。我想知道Clustered和Non clustered indexes。我用谷歌搜索，我发现的是：

聚集索引是一种特殊类型的索引，它对表中记录的物理存储方式进行重新排序。因此表只能有一个聚集索引。聚集索引的叶节点包含数据页。非聚集索引是一种特殊类型的索引，其中索引的逻辑顺序与磁盘上行的物理存储顺序不匹配。非聚集索引的叶节点不包含数据页。相反，叶节点包含索引行。

我在 SO 中发现的是聚集索引和非聚集索引有什么区别？.

有人可以用简单的英语解释一下吗？

我使用的是SQL Server 2008。我知道如果一个表没有聚集索引，那么它被称为堆，否则存储模型称为聚集索引（B-Tree）。

我想了解更多关于堆存储的确切含义、它的外观以及它是否被组织为“堆”数据结构（例如最小堆、最大堆）的更多信息。有什么推荐的读物吗？我想要更多的内部知识，但不要太深。:-)

提前谢谢，乔治

我正在使用 Fluent-NHibernate（带有自动映射）来生成我的表，但想选择与默认使用的 ID 字段不同的聚集索引。如何使用 Fluent NHibernate 在默认主键字段以外的字段上创建聚集索引？

这背后的主要原因很简单。我将 Guids 用于我的主键字段。默认情况下，NHibernate 在主键字段上创建聚集索引。由于 Guid 通常不是顺序的，因此在主键字段上进行聚类会导致性能问题。

众所周知，在表的末尾追加记录比在表中插入记录要便宜得多。此外，表中的记录在物理上按照聚集索引中的项目顺序存储。由于 Guid 在某种程度上是“随机的”并且不是连续的，因此可能会生成小于表中已经存在的其他 Id Guid 的值的新 Guid - 导致表插入而不是追加。

为了尽量减少这种情况，我有一个名为 CreatedOn 的列，它的类型为 DateTime。我需要将表聚集在这个 CreatedOn 列上，以便附加而不是插入所有新记录。

欢迎任何关于如何实现这一点的想法！！！

注意：我意识到我可以使用 Sequential Guid，但出于安全原因，我不想走这条路。

注意：我仍然没有对这篇文章的答案，但我目前正在思考一些想法。

1. 在没有 Fluent 的情况下使用 NHibernate，我认为可以直接在 NHibernate 中创建聚集索引。我对 NHibernate 的了解还不够，不知道如何做到这一点。我只是很漂亮（几乎绝对）确信它可以完成。

2. Fluent-NHibernate 曾经包含一种在最近重写之前在 SQL 对象上设置属性（例如，聚集索引）的方法。现在这个选项似乎已经消失了。我可能会在某处发布一个问题，看看该选项是否仍然可用。如果是这样，我可能会使用它来设置聚集索引。

3. Fluent-NHibernate 提供了在流畅构建后公开配置以进行手动编辑的能力。我没有尝试过这个功能，但希望它可以提供设置聚集索引所需的粒度级别。

4. 最坏的情况是，我可以编写一个 SQL 脚本来更改所有表上的聚簇索引，一旦它们生成。但是，我对这种方法有几个问题。A. 由于我使用自动模式生成，NHibernate 会在下次评估配置时“撤消”我的聚集索引更改吗？2. NHibernate 检测到聚集索引被改变了会报错吗？我需要对此进行测试，但还没有这样做。我真的很讨厌这个解决方案。我正在针对 SQLServer2008 和 MySQL 测试我的数据库。NHibernate 的部分优点在于它与数据库无关。一旦我们引入脚本，所有的赌注都没有了。

5. 有一个在称为 IPropertyInstance 的流式约定中使用的接口，从该接口继承的类具有一个 Index 属性，该属性允许在该字段上创建索引。问题是没有标志或其他选项允许将索引创建为聚集索引。最简单的解决方案是向此方法添加一个属性以允许创建聚集索引。我想我可能会向 Fluent-NHibernate 开发人员建议这个。

我在 SQL Server 中有一个表，需要将其正常的 pk 索引替换为两个字段上的聚集索引。这些其他字段不是主键的一部分。

我需要在 Oracle 中做类似的事情。据我所知，这可以使用按索引排序的表来完成，但我猜这些索引仅在主键上构建。

有什么方法可以让我在 Oracle 中获得与 SQLServer 的聚集索引类似的行为？

我在 SQL Server 2005 中有一个存储过程，当我运行它并查看它的执行计划时，我注意到它正在执行聚集索引扫描，这花费了 84%。我读过我必须修改一些东西才能在那里获得聚集索引搜索，但我不知道要修改什么。

我会很感激这方面的任何帮助。

谢谢，

布赖恩

我有一系列关于 SQL，特别是 SQL 2005 中的键、索引和约束的问题。我已经使用 SQL 大约 4 年了，但我从来没有能够得到关于这个主题的明确答案，而且在博客文章等上总是有相互矛盾的信息。我创建和使用的大多数时间表只有一个 Identity 列是主键，其他表通过外键指向它。

使用连接表，我没有身份，并在外键列上创建复合主键。以下是我目前的信念的一组陈述，可能是错误的，如果是，请纠正我，以及其他问题。

所以这里是：

据我了解，聚集索引和非聚集索引之间的区别（无论它是否唯一）是聚集索引会影响表中数据的物理顺序（因此表中只能有一个），而非聚集索引构建树数据结构。创建索引时，为什么我应该关心集群与非集群？我什么时候应该使用其中一种？有人告诉我，非聚集索引的插入和删除速度很慢，因为树需要“重建”。我认为聚集索引不会影响性能吗？

我看到主键实际上只是唯一的聚集索引（它们必须聚集吗？）。主键与聚集唯一索引有什么特别之处？

我也见过约束，但我从未使用过它们或真正看过它们。有人告诉我，约束的目的是强制数据完整性，而索引的目的是提高性能。我还读到约束实际上是作为索引实现的，因此它们是“相同的”。这对我来说听起来不对。约束与索引有何不同？

我有一个应用程序，其中指令说它不适用于具有多个字段的聚集索引。无法抗拒测试，这是真的。如果我添加一个包含 2 个字段的聚集索引，该应用程序就会陷入无休止的 lopp 中。

我认为索引是数据库内部的东西，不会影响应用程序。在聚集索引的情况下如何编写不起作用的 sql？

该应用程序正在使用 sql server 2005

考虑以下复合聚集索引：

显然， b上的单独索引将使搜索 b 的特定值更快。

但是，如果不使用b上的单独索引，在我看来，复合索引仍然可以用于查找具有特定b值的元组，而不是表扫描，方法是遍历a的离散值树并执行a 本地搜索b，跳转到 a 的下一个值，等等。

SQL Server 是这样工作的吗？（例如，如果 MSSQL 对具有多列的索引使用单个哈希值，则不会。）

确实如此，并且由于其他原因已经需要复合索引，并且 a 的离散值的数量足够小，性能/空间权衡可能会偏离为b设置单独的索引。

（上面的 UNIQUE 和 CLUSTERED 约束对于这个例子来说并不是真正需要的，但它们代表了 b 的最快检索，不涉及b的单独索引——前者为 a 的每个循环提供快捷方式，后者删除查找中的一级间接性）。