1

由于我们最近遇到的一些数据库问题,我一直在查看索引的状态并尝试减少碎片。

该应用程序有几个名称表,例如 BoysNames 和 GirlsNames,我们使用它们来设置我们创建的 User 对象的属性。这里最明显的属性是 Gender。这些表可以有几百到 10,000 行。

这些表的结构如下:

Name - nvarchar(50) - PK & Clustered Index
DateCreated - datetime

当我告诉 Sql Server 重新组织或重建我所有表上的索引时,大多数表碎片下降到 0%,但其中一些 Name 表立即碎片化了 50%。

我只在 2 个地方访问这些表:

  1. 第一个是当我从表中选择每个名称并将其存储在内存中以针对进入系统的新用户使用,这样我就可以执行以下操作: if (boysNames.Contains(user.Name)) {user.Gender = "米"}; 这种情况经常发生。
  2. 第二个是当我向列表中添加新名称时,我检查名称是否存在,如果它不存在,我添加它。这种情况很少发生。

所以我需要知道的是:

这种高度的碎片化会给我带来问题吗?在重组/重建后直接将索引碎片设置为 50% 时,如何将索引碎片减少到 0%?

我应该使用 int 作为主键并在 Name 上放置索引,还是 nvarchar 是主键的正确选择?

4

1 回答 1

0

如果索引页常驻在内存中(可能只有那几行),那么碎片就无关紧要了。您可以通过count(*)查询对其进行基准测试。从第二次执行开始,您应该会看到内存速度。如果您现在比较 100% 和 0% 碎片表的结果,您应该看不出有什么区别。

我不认为你有问题。如果您坚持,您可以将填充因子设置为低于 100,以便在随机位置插入行时有空间容纳新行。从 90 开始并以 5 为增量降低,直到您对速率碎片化的发展感到满意为止。

IDENTITY字段进行聚类会删除聚集索引的碎片,但您可能需要一个索引,在Name该索引上再次出现碎片。如果您根本不需要任何索引,请将其设为堆表并完成它。不过,我非常反对这一点。

于 2013-10-25T15:54:29.787 回答