主页 / dba / 问题 / 187485
Accepted
Philip
Asked: 2017-10-03 15:19:46 +0800 CST

如何通过统计更新最好地管理索引构建？

  • 772

这是我阅读的后续内容是否有任何理由在维护窗口期间停止事务日志备份？在 sp_BlitzErik 提出的答案中。

我使用 Ola Hallengren 的索引脚本并按照以下指定设置。我每周通过代理工作运行一次。

@Databases nvarchar(max),
@FragmentationLow nvarchar(max) = NULL,
@FragmentationMedium nvarchar(max) = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh nvarchar(max) = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 int = 5,
@FragmentationLevel2 int = 30,
@PageCountLevel int = 500,

我知道作为索引重建的一部分，更新统计信息是自动完成的，但是我针对我的所有数据库设置了以下数据库属性，我认为这些属性应该负责更新统计信息：

Auto Create Statistics = True
Auto Update Statistics = True
Auto Update Statistics Asynchronously = True

这些设置和定期更新统计信息的最佳实践通常是什么？你应该每晚更新统计数据吗？我不确定如何衡量是否应该更新统计信息，这就是我设置这些数据库属性的原因。

我在 sp_BlitzErik 的回答中看到他提到“你仍然想要定期更新统计数据，你可以用这个命令来做到这一点：”

使用以下命令，但定期更新统计信息非常普遍。

EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES',
                          @FragmentationLow = NULL,
                          @FragmentationMedium = NULL,
                          @FragmentationHigh = NULL,
                          @UpdateStatistics = 'ALL',
                          @OnlyModifiedStatistics = 'Y',
                          @StatisticsSample = NULL,
                          @LogToTable = 'Y';
sql-server statistics

1 个回答

  1. Best Answer

    我使用 Ola Hallengren 的索引脚本并按照以下指定设置。我每周通过代理工作运行一次。

    让我们分解您正在运行的命令：

    @FragmentationLevel1 int = 5,
@FragmentationLevel2 int = 30,
@PageCountLevel int = 500,

    即使每周一次，这也是荒谬的侵略性。我知道 5/30% 来自古老的微软建议，但它只是——古老。是时候继续前进了。

    您正在花时间对 500 个 8KB 页的索引进行碎片整理。那是一个 4MB 的表。如果您的硬件在将 4MB 数据读入内存或在内存中保留 4MB 表时出现问题，那么答案不是索引维护。这就是为什么我将其提高到至少 5000 的原因。

    现代硬件，如 SAN、SSD 和非 32 位服务器，可以容纳大于 4GB 的 RAM，根本不存在与 2000 年代早期的旋转盘驱动器相同的数据访问问题。

    我们谈论的是电唱机与 CD。

    索引重建应该极少发生，并且仅用于更正索引问题或更改设置。事情是这样的：30% 的碎片并不是真正的问题。这只是 DBA 做的事情，因为他们被告知要这样做，而且这是他们可以衡量的事情。

    所以这是我要问你的问题：你的服务器在索引维护上花费了多少时间和资源，这又减少了多少查询消耗的时间和资源？

    如果你能衡量这一点，你就可以随心所欲地重建和重组。

    ...但是我针对我的所有数据库设置了以下数据库属性，我认为应该负责更新统计信息...

    有点像。当 20% 的表数据 + 500 行（假设表 > 500 行）更改时，会发生自动更新统计信息（甚至异步）。如果您有一个包含一百万行的表，那就是 20 万行。您可以使用跟踪标志 2371 动态降低该阈值，但自动更新统计信息使用默认采样算法，这对于数据严重倾斜的表可能不够用。

    但定期更新统计数据是非常普遍的。

    嗯，是的，我正在回答有关我从未看过的服务器的问题。我更喜欢夜间统计更新，但我见过比这更频繁地需要它们的服务器。

    那你该怎么办？

    1. 首先将索引维护回拨到我在您引用的问题中发布的命令

      如果遇到问题，请降低碎片阈值直到问题停止。如果没有人说什么，请减少运行索引维护的频率，直到也许，只是也许，您根本不运行它。

    2. 每晚更新统计数据

      从默认阈值开始。如果您发现重建时发生的完整统计信息更新是必要的，请使用该CommandLog表查找定期重建哪些表和索引，并开始关注这些。它们通常是具有数千万行的“大”表的索引。

    这是关于我从未见过的服务器的具体信息。你将不得不从这里进行实验。

    另请参阅我的帖子为什么你们中的大多数人应该将自动更新统计信息保留在

    • 3

相关问题