相关疑难解决方法(0)

我继承了执行以下操作的维护计划：

• 清理旧数据
• 检查数据库完整性
• 执行数据库和事务日志备份
• 重组我们的索引
• 更新统计
• 删除旧备份和维护计划文件

在 23 分钟的维护计划中，更新统计数据需要惊人的 13 分钟。在这 13 分钟期间，对数据库的访问被阻止（或者至少，从这个数据库到我们其他数据库的复制被暂停）。

我的问题是：

我们应该什么时候更新统计数据，为什么？

这似乎是我们应该比每天少做的事情。我试图让我们摆脱“仅仅因为”进行不必要维护的心态。

维护全文索引应考虑哪些准则？

我应该重建还是重组全文目录（请参阅BOL）？什么是合理的维护节奏？可以使用哪些启发式方法（类似于 10% 和 30% 碎片阈值）来确定何时需要维护？

（下面的所有内容只是详细说明该问题并显示我到目前为止所想的内容的额外信息。）

额外信息：我的初步研究

有很多关于 b 树索引维护的资源（例如，这个问题、Ola Hallengren 的脚本以及来自其他站点的大量关于该主题的博客文章）。但是，我发现这些资源都没有提供用于维护全文索引的建议或脚本。

有Microsoft 文档提到对基表的 b 树索引进行碎片整理然后在全文目录上执行重组可能会提高性能，但它没有涉及任何更具体的建议。

我也发现了这个问题，但它主要关注更改跟踪（如何将底层表的数据更新传播到全文索引中），而不是可以最大化索引效率的定期维护的类型。

额外信息：基本性能测试

此SQL Fiddle包含的代码可用于创建带有AUTO更改跟踪的全文索引，并在修改表中的数据时检查索引的大小和查询性能。当我在生产数据的副本上运行脚本的逻辑（而不是小提琴中的人工制造数据）时，以下是我在每个数据修改步骤后看到的结果的摘要：

尽管此脚本中的更新语句相当人为，但这些数据似乎表明定期维护可以获得很多好处。

额外信息：初步想法

我正在考虑创建一个每晚或每周的任务。似乎此任务可以执行 REBUILD 或 REORGANIZE。

因为全文索引可能非常大（数千万或数亿行），所以我希望能够检测目录中的索引何时足够碎片化，从而需要进行 REBUILD/REORGANIZE。我有点不清楚什么启发式可能对此有意义。

在网上搜索后，我找不到原因

1. 为什么我们需要在 SQL Server 中重建和重组索引？

2. 当我们重建和重组时，内部会发生什么？

网站上的一篇文章说：

当索引碎片大于 40% 时应该重建索引。当索引碎片在 10% 到 40% 之间时，应该重新组织索引。索引重建过程使用更多 CPU 并锁定数据库资源。SQL Server 开发版和企业版有 ONLINE 选项，可以在重建 Index 时开启。ONLINE 选项将在重建期间保持索引可用。

我无法理解这一点，虽然它说WHEN要这样做，但我想知道WHY我们是否需要重建和重组索引？

我有一个包含 490 M 行和 55 GB 表空间的表，所以每行大约 167 个字节。该表包含三列： a VARCHAR(100)、 aDATETIME2(0)和 a SMALLINT。VARCHAR字段中文本的平均长度约为 21.5，因此原始数据每行应约为 32 个字节： 22+2 表示VARCHAR， 6 表示DATETIME2，2 表示 16 位整数。

请注意，上面的空间仅是数据，而不是索引。我正在使用属性下报告的值 | 存储 | 一般 | 数据空间。

当然肯定会有一些开销，但是每行 135 个字节似乎很多，尤其是对于大表。为什么会这样？有没有其他人见过类似的乘数？哪些因素会影响所需的额外空间量？

为了进行比较，我尝试创建一个包含两个INT字段和 1 M 行的表。所需的数据空间为 16.4 MB：每行 17 个字节，而原始数据为 8 个字节。另一个测试表中的 anINT和 aVARCHAR(100)填充了与真实表相同的文本，每行使用 39 个字节（44 K 行），我预计 28 加上一点。

所以生产表有更多的开销。这是因为它更大吗？我希望索引大小大约为 N * log(N)，但我不明白为什么实际数据所需的空间是非线性的。

在此先感谢您的指点！

编辑：

列出的所有字段都是NOT NULL. …

我们有一位 SQL 专家建议每周重建我们的表索引。我们目前正在这个星期六晚上进行，它会在重建过程中导致很多超时。如果可能，我想避免超时，那么进行每周索引重建是个好主意吗？

我们正在运行 MS SQL Server 2014。

更新我们在重建过程中收到此错误“System.Data.SqlClient.SqlException：超时已过期。操作完成之前超时时间已过，或者服务器没有响应。”

谢谢！

什么时候应该重建索引？vs 重组？

什么索引碎片值被认为是健康的？