问题标签 [clustered-index]

我刚刚意识到我在 Timestamp 上有一个以降序排列的聚集索引。我正在考虑将其切换为升序，以便在插入新的、不断增加的时间戳时，将它们添加到表的末尾。就目前而言，我怀疑它必须在表的开头添加行，我想知道 SQL Server 是如何处理的。

它是否可以在表的开头有效地分配新页面，并有效地将新行插入这些页面，或者按照时间戳的顺序填充页面并在末尾使用升序聚集索引分配新页面会更好。

PRIMARY KEY 关键字与 SQL Server 中的聚集索引有何关系？

（有些人似乎想回答这个问题，而不是我问的另一个问题，所以我给他们一个更好的地方这样做。）

当一个表在 SQL Server 中具有聚集索引时，这是否意味着所有索引查询都将通过聚集索引进行？

例如，如果我有一个带有单个非聚集索引（索引一列）的表并通过该列搜索一行，它将执行Index Seek -> RID -> Data row lookup -> Result

但是，如果我在不同的列上添加聚集索引，那么相同的查询将执行以下操作Index Seek -> Extract clustering key -> Clustered index seek -> Results

这对我来说意味着非聚集索引不再以叶处的 RID 而是以聚集索引的聚集键“终止”？那正确吗？

我的两个问题是：

• 我可以使用聚集索引来加速大表中的批量插入吗？
• 如果我的 IDENTITY 列不再是聚集索引，我还能有效地使用外键关系吗？

详细地说，我有一个数据库，其中包含几个非常大的（100-10 亿行之间）表，其中包含公司数据。通常在这样的表中有大约 20 到 40 家公司的数据，每家公司都是由“CompanyIdentifier”（INT）标记的自己的“块”。此外，每家公司都有大约 20 个部门，每个部门都有自己的“子块”，用“部门标识符”(INT) 标记。

经常会从表中添加或删除整个“块”或“子块”。我的第一个想法是在这些块上使用表分区，但由于我使用的是 SQL Server 2008 标准版，因此我无权使用它。尽管如此，我的大多数查询都是在“块”或“子块”上执行的，而不是在整个表上执行的。

我一直在努力针对以下功能优化这些表：

1. 在子块上运行的查询
2. 在整个表上运行的“基准测试”查询
3. 插入/删除大块数据。

对于1）和2）我没有遇到很多问题。我已经在关键字段上创建了几个索引（还包含有用的 CompanyIdentifier 和 DepartmentIdentifier）并且查询运行良好。

但是对于 3) 我一直在努力寻找一个好的解决方案。我的第一个策略是始终禁用索引，批量插入一大块并重建索引。一开始这个速度很快，但是现在数据库里有很多公司，每次重建索引都需要很长时间。

目前，我的策略已更改为仅在插入时保持索引打开，因为现在这似乎更快。但我想进一步优化插入速度。

我似乎注意到通过添加在 CompanyIdentifier + DepartmentIdentifier 上定义的聚集索引，将新“块”加载到表中更快。在我放弃此策略以支持在 IDENTITY 列上添加聚集索引之前，正如几篇文章向我指出的那样，聚集索引包含在所有其他索引中，因此聚集索引应该尽可能小。但现在我正在考虑恢复这种旧策略以加快插入速度。我的问题是，这是否明智，或者我会在其他领域遭受性能打击？这真的会加快我的插入速度还是只是我的想象？

我也不确定在我的情况下是否真的需要一个 IDENTITY 列。我希望能够与其他表建立外键关系，但我也可以为此使用 CompanyIdentifier+DepartmentIdentifier+[uniquifier] 方案吗？或者它必须是一个表范围的、碎片化的 IDENTITY 编号？

非常感谢任何建议或解释。

我正在尝试通过Java Tutorial进行工作。

作者编写了使用 MS SQL 的教程。我想按照使用 MySQL 的教程进行操作。我不完全确定如何翻译使用“IDENTITY”、“CONSTRAINT”和“CLUSTERED”的 MS SQL 脚本，如下所示：

据我所知，这是：

...但我担心省略的代码会导致功能丢失，甚至与教程的其余部分不兼容。

有没有更好的方法我应该写这个？

我现在明白聚集索引包含所有行数据，而不仅仅是索引字段。我试图了解这对碎片化的影响。

假设我们有一个这样的表：

现在假设所有这些行都充满了数据，然后在聚集索引中的一些较早的行上，您突然将 Field1、Field2、Field3 和 Binary 设置为空。

正如我以我相当幼稚的方式认为的那样，这其中的一个含义是，清除所有这些值会产生差距，索引会变得支离破碎。我猜这些行的顺序仍然正确，那真的是索引碎片吗？

或者你可以换个角度想；如果它们一开始都是空的并且您插入数据，那么您最终是否不得不将数据洗牌到不同的页面并获得索引碎片？

此外，我知道 LOB 数据存储在单独的分配单元中，尽管我不确定这意味着什么；这是否意味着将 Binary 设置为 null （或填充它）应该对聚集索引碎片没有影响？

我有一个包含许多列的表，其中总的最大大小大大超过了 8k 边界。这个表包含一个 ModuleID 列，它基本上告诉你它是什么类型的对象（不要担心——我没有设计这个），其中可能有 15 个不同的值。然后它有一个名为 propertyID 的唯一列，它也是一个 IDENTITY(1,1)，然后由 SQL Server 递增。ModuleID 上有一个聚集索引，这个值对于选择总是已知的，更新时使用 propertyID（moduleID 很少在此范围内）。表包含几百万行。

因此，关于 INSERT，我的问题是：
a) 非唯一聚集键是否会增加 SQL Server 持有独占页级锁而不是键（行）锁的可能性？
b) 将聚集键更改为递增的唯一 propertyID 将使 SQL Server 能够持有独占 KEY 锁，而这些总是会进入聚集索引的最后一页？

表（在某些安装中）在 moduleID 上分区的事实会改变你的答案吗？

默认情况下，MongoDB 在文档中的 _id 键上创建索引。但是当我确保额外的索引（在 MySQL 中的 InnoDB 中是二级索引？）并在之后查询它时，引擎会扫描它，然后选择性扫描 _id 索引以获取文档偏移量？

我很困惑，因为当分片出现时，我是对的，每个块都有自己的索引，每个查询会有很多随机读取？

我的一位同事的印象是，在 SQL Server 2008 中向表中添加索引时，PK 的索引也会添加到该索引中。因此，如果您使用更广泛的主键，那么该键也将包含在新索引中，这大大增加了所使用的磁盘空间，超出了已经为 PK 上的索引支付的惩罚。我以前没有听说过，到目前为止我的搜索是空的。

希望这里有人可以向我指出相关文档以确认或否认这一点。请？

想从中得到一些建议。我有一张表，我想在其中跟踪一个对象以及与该对象相关的键列表。例子：

OBJECTID 和ITEMKEY 都具有很高的选择性（即OBJECTID 和ITEMKEY 变化很大）。我的访问有两种方式：

• 按 OBJECTID：每次对象更改时，键列表都会更改，因此需要基于 OBJECTID 的键。变化经常发生。

• By ITEMKEY：这是用于关键字搜索，也经常发生。

所以我可能需要两个键，并为聚集索引选择一个（更频繁访问的那个，或者我希望速度达到的位置，现在假设我将优先考虑聚集的 OBJECTID）。我很困惑的是我应该如何设计它。

我的问题是，哪个更好：

a) (OBJECTID,ITEMTYPE,ITEMKEY) 的聚集索引，然后是 (ITEMKEY) 的索引。我担心的是，由于聚集索引太大（2 个整数，1 个字符串），索引会很大，因为所有索引项都必须指向聚集键。

b) 创建一个以运行标识 DIRECTORYID (integer) 作为主键和聚集索引的新列，并为 (OBJECTID,ITEMTYPE,ITEMKEY) 和仅 (ITEMKEY) 声明两个索引。这将最小化索引空间但具有更高的查找成本。

c) (OBJECTID,ITEMTYPE,ITEMKEY) 的聚集索引，以及 (ITEMKEY,ITEMTYPE,OBJECTID) 的物化视图。我的逻辑是，这避免了键查找，并且仍然与在 a) 中查找的索引一样大，但代价是更高的开销。

d）Err ...根据要求，也许有更好的方法？

在此先感谢，安德鲁