问题标签 [clustered-index]

clustereda和 a 有什么区别non-clustered index？

我有几个关于不使用索引是否最好的问题。

背景：我的记录有时间戳属性，记录会按照时间戳的顺序插入（即按时间顺序插入）。

问题：

1. 如果我不使用索引，数据库是否通常按照插入的顺序插入记录？

2. 如果对#1 的回答是肯定的，那么当我执行“SELECT .. WHERE timestamp > X”类型查询时，数据库是否会有效，或者它是否必须遍历每条记录，因为它没有被索引？我假设如果没有索引，数据库将不会“知道”记录是按排序顺序插入的，因此无法使用数据库的排序属性。

我认为聚集索引最适合这些类型的记录及其插入。

请让我知道你们的想法。

谢谢，jbu

我正在研究一个通常使用 GUID 作为主键的数据库。

默认情况下，SQL Server 在主键列上放置一个聚集索引。我知道这对于 GUID 列是一个愚蠢的想法，并且非聚集索引更好。

你怎么看 - 我应该摆脱所有聚集索引并用非聚集索引替换它们吗？

为什么 SQL 的性能调整器不提供此建议？

最近有几个关于数据库索引和聚集索引的问题，直到最近几周，这对我来说都是新的。我想知道它的重要性以及创建它们可以获得什么样的性能提升。

编辑：当您第一次开始时放入聚集索引时，通常最好查看的字段类型是什么？

编辑：我添加了“Slug”列来解决特定记录选择的性能问题。

我的表格中有以下列。

大多数时候，我按 EntryDate 订购 select 语句，如下所示。

如果有重复的EntryDates，我将按EntryDate 和Id 对其进行排序。

当我选择 A 记录时，我执行以下操作。

我有一个独特的 Slug & EntryDate 键。

在我的情况下，什么是键和索引的明智选择？我面临性能问题可能是因为我按未聚集索引的列排序。

我应该将 Id 设置为非聚集主键并将 EntryDate 设置为聚集索引吗？

我感谢您的所有帮助。谢谢。

编辑：

我没有尝试在 EntryDate 上添加非聚集索引。从后端插入的数据，因此插入的性能对我来说没什么大不了的。此外，EntryDate 并不总是插入日期。它可以是过去的日期。后端用户选择日期。

有问题的表是供应商软件在我们网络上使用的数据库的一部分。该表包含有关文件的元数据。表的架构如下

ResultID 和 Fieldname 上有一个聚集索引。该表通常包含数百万行（在一种情况下，它包含 5 亿行）。该表由 24 个工作人员填充，每个工作人员在“处理”数据时运行 4 个线程。这会导致许多非顺序插入。稍后在处理后，我们的一些内部软件将更多数据插入到此表中。给定表的碎片至少为 50%。对于最大的表，它是 90%。我们没有 DBA。我知道我们迫切需要一个数据库维护策略。就我的背景而言，我是一名在这家公司兼职的大学生。

我的问题是，聚集索引是解决这个问题的最佳方法吗？是否应该考虑另一个索引？对于这种类型和类似的临时 DBA 任务，是否有任何好的参考资料？

我有一个包含大量行（10K+）的表，它的主键是 GUID。主键是集群的。此表的查询性能相当低。请提供建议以使其高效。

我需要开发用于分布式环境的数据库索引的“简单”实现。我对这个主题几乎一无所知，而且我有点被时间压力。

我很想听听关于这个主题的一些意见、例子和算法。我希望能够对我需要实现的内容有一个心理表征。

编辑：我指的是聚集索引

我很想知道是否有人知道数据在没有索引（甚至没有 PK）的表中是如何物理排列的。在这个问题中，OP 声称删除集群 PK 需要很长时间。我知道聚集索引就是数据本身，但是解释长处理时间的新数据排列是什么？

我有一个表，它在两列上有一个聚集索引 - 表的主键。定义如下：

我想删除此聚集索引 PK 并添加如下聚集索引并使用非聚集索引添加主键约束，如下所示。

我打算只删除 PK 聚集索引，然后添加新的聚集索引，然后添加非聚集主键索引，但我了解到删除现有聚集索引会导致表数据重新排序（请参阅此处的答案What当我在 SQL 2005 中删除集群主键时发生），我认为这不是必需的。该表正在敲 1 TB，所以我真的想避免任何不必要的重新排序。

我的问题是，从现有结构到所需结构的最佳方式是什么？

编辑：只是想澄清一下。该表为 1TB，不幸的是我没有空间来创建临时表。如果有办法在不创建临时表的情况下做到这一点，请告诉我。