问题标签 [clustered-index]

我想在我的表中添加索引。我正在寻找如何向表中添加更多索引的一般想法。除了 PK 集群。我想知道当我这样做时要寻找什么。所以，我的例子：

这个表（我们称之为 TASK 表）将成为整个应用程序中最大的表。期待数百万条记录。

重要提示：大量批量插入正在此表中添加数据

表有 27 列：（到目前为止，还在计数：D）

int x 9 列 = id-s

varchar x 10 列

位 x 2 列

日期时间 x 5 列

整数列

所有这些都是 INT ID，但来自通常小于任务表（最多 10-50 条记录）的表，例如：状态表（具有诸如“打开”、“关闭”之类的值）或优先级表（具有诸如“重要”，“不太重要”，“正常”）还有一个类似“父ID”的列（self-ID）

加入：所有“小”表都有PK，通常的方式......集群

字符串列

有一个（公司）列（字符串！）类似于“一直有 5 个字符”，每个用户都将被限制使用这个。如果在 Task 中有 15 个不同的“公司”，则登录用户只会看到一个。所以总是有一个过滤器。向该列添加索引可能是个好主意？

日期栏

我认为他们没有索引这些......对吗？或者可以/应该是？

好的，我需要再说明一次。我在网上看过文章，但我仍然没有找到明确的答案。

在 SQL Server 2008 中，我有一个“核心”表，其中包含大约 50k 条记录和大量读取活动，在所有查询中都以相同的方式使用。该数据每月更新一次，每秒读取数百次。

数据在字段上具有聚集索引，因为它们经常被访问。假设聚集索引是：

聚集索引

现在，没有比这更多的数据了，因此将额外的几列放入“包含的列”是有意义的，但 SQL Server 不允许在聚集索引中包含列。

因此，我们有第二个索引，其字段与聚集索引基本相同，其他列为“包含列”。但是，根据我的阅读，我相信这可能是多余的？

覆盖索引（非聚集）

包含的列

非聚集索引是否已经定义了聚集索引中的列？

如果是这样，那么如何创建第二个索引时根本没有列（除了聚集索引中已经存在的内容）？换句话说，我想说“这个索引与聚集索引完全相同......带有几个包含列”。

或者，将所有列放入聚集索引（包括不识别记录的两个）会更好吗？varchar 列确实会更频繁地更新（每天几次而不是每月一次），所以我希望将它们排除在聚集索引之外，但我认为它们足够深，不会影响索引树足以在发生更改时引起任何重新平衡。

那么，有没有一种有效的方法来设置这些索引，以便该表的所有列都可以通过索引获得，而无需返回该表？

我有一个存储员工详细信息的 SQLServer 表，列 ID 是 GUID 类型，而列 EmployeeNumber 是 INT 类型。大多数时候，我会在进行连接和选择标准时处理 EmployeeNumber。

我的问题是，将 PrimaryKey 分配给 ID 列而 ClusteredIndex 分配给 EmployeeNumber 是否明智？

编辑

@Remus 纠正了我的测试模式。您可以在下面的答案中看到更正的版本。

我接受了用 DECIMAL(29,0) 替换 INT 的建议，结果是：

十进制：2133
GUID：1836

随机插入仍然获胜，即使行稍大。

尽管解释表明随机插入比顺序插入慢，但这些基准测试表明它们显然更快。我得到的解释与基准不一致。因此，我的问题仍然集中在 b 树、顺序插入和速度上。

...

我从经验中知道，当数据按顺序添加到 b 树时（无论方向如何），它们的性能都很糟糕。但是，当随机添加数据时，可以获得最佳性能。

这很容易用 RB-Tree 之类的东西来演示。顺序写入会导致执行最大数量的树平衡。

我知道很少有数据库使用二叉树，而是使用 n 阶平衡树。我从逻辑上假设它们在顺序输入方面遭受与二叉树相似的命运。

这激发了我的好奇心。

如果是这样，那么可以推断出写入顺序 ID（例如在 IDENTITY(1,1) 中）会导致树发生多次重新平衡。我看到许多帖子反对 GUID，因为“这些会导致随机写入”。我从不使用 GUID，但令我震惊的是，这个“坏”点实际上是一个好点。

所以我决定测试一下。这是我的代码：

请注意，我并没有减少创建 GUID 的任何时间，也没有减少行的相当大的额外大小。我的机器上的结果如下：

诠释：17,340 毫秒 GUID：6,746 毫秒

这意味着在这个测试中，随机插入 16 字节几乎比连续插入 4 字节快 3 倍。

有人愿意对此发表评论吗？

附言。我知道这不是一个问题。这是一个讨论的邀请，这与学习最佳编程有关。

我有一个大表，我必须从中选择大量行。

该表存储呼叫详细记录 (CDR)。例子：

由于我的查询会在特定日期查找客户电话，因此我在聚集索引中将 calldate 和 accountcode 一起编入索引，如下所示：

但是，在执行以下查询时，EXPLAIN 结果显示只使用了键的日期时间部分：

询问：

解释结果：

似乎只使用了前 8 个字节（密钥的日期部分）。然而，WHERE 子句用 AND 显式引用键的两个部分，因此理论上应该使用完整键。

我应该为 calldate 和 accountcode 创建单独的索引并让查询优化器合并它们吗？为什么不使用完整索引？

谢谢您的帮助！

我有一个跨越多个字段的聚集索引。这些字段之一是 CustomerID。我有一个从该表中读取的游标，然后更新 CustomerID。问题是它会导致无限循环。我假设当它更改 customerid 字段时，会修改聚集索引并为索引重新构建表。此修改似乎使我的光标无效，因此 FETCH NEXT FROM Cursor 永远不会到达末尾。

我可以发出任何命令来阻止表更新聚集索引的表，直到光标完成？

我正在使用 psql 访问 postgres 数据库。在查看表的元数据时，有什么方法可以查看表的索引是否为聚集索引？

听说表的 PRIMARY KEY 会自动关联聚集索引，是真的吗？

尽管有可用的分区功能和方案，但如何在未分区的表上创建分区索引。这是我在某处读到的练习，不是真正的问题

我在想

但是表没有分区，那么如何在不分区表的情况下创建索引呢？

我需要在index我的表格中添加适当的内容并需要一些帮助。

我很困惑，需要澄清几点：

• 我应该对non-int列使用索引吗？为什么/为什么不

• 我已经阅读了很多关于clustered和non-clustered索引的内容，但我仍然无法决定何时使用其中一个。一个很好的例子会帮助我和许多其他开发人员。

我知道我不应该对经常更新的列或表使用索引。在进入测试阶段之前，我还应该注意什么？我怎么知道一切都很好？

这份 2007 年的白皮书比较了单个 select/insert/delete/update 和 range select 语句在组织为聚集索引的表上与在与 CI 相同的键列上具有非聚集索引的堆组织的表上的性能桌子。

通常，聚集索引选项在测试中表现更好，因为只需维护一个结构并且不需要书签查找。

本文未涵盖的一个可能有趣的案例是堆上的非聚集索引与聚集索引上的非聚集索引之间的比较。在那种情况下，我预计堆甚至可能会表现得更好，因为一旦在 NCI 叶级 SQL Server 有一个 RID 可以直接遵循，而不需要遍历聚集索引。

有没有人知道在这个领域已经进行了类似的正式测试，如果有，结果如何？