关于数据库统计信息
用于查询优化的统计信息是包含有关表或索引视图的一列或多列中值分布的统计信息的对象。 查询优化器使用这些统计信息来估计查询结果中的基数或行数。 这些基数估计使查询优化器能够创建高质量的查询计划。
例如，查询优化器可以使用基数估计来选择索引查找运算符而不是资源密集型索引扫描运算符，从而提高查询性能。 否则，过时的统计信息可能会通过使用低效的查询计划来降低查询性能。
大型企业 SharePoint 部署必须具有数据库维护计划，才能更新驻留在 Microsoft SQL Server 中的内容数据库的数据库统计信息。 客户不应仅依赖基于 SharePoint 的数据库维护作业来执行这些任务。 有关详细信息，请参阅 SharePoint Server 服务器场中 SQL Server 的最佳实践。
症状
当数据库统计信息过时时，SharePoint Server 安装可能会遇到以下一个或多个症状：
加载时间缓慢，性能降低，在打开网站页面时可能会生成 HTTP 500 错误
性能较慢，生成错误消息，如以下示例：
Service unavailable Unknown SQL Exception 53 Server Error in '/' Application Runtime Error执行搜索爬网会导致意外SQL Server性能、数据库锁定和阻塞
长时间运行的计时器作业，例如“Microsoft SharePoint Foundation 使用情况数据处理”作业，每次迭代期间需要逐渐更长的时间才能完成。
无法打开 SharePoint 网站，以及如下所示的错误消息：
Unexpected System.Web.HttpException: Request timed out加载导航时网站呈现超时，并显示以下错误消息：
PortalSiteMapProvider was unable to fetch children for node处理 SharePoint 查询时运行 SQL Server 的服务器上的 CPU 使用率过高
原因
这些问题可能是由过时的数据库统计信息引起的。 SharePoint 每天运行计时器作业，以使用 proc_updatestatistics SQL 过程更新数据库统计信息。 但是，由于各种原因，此计时器作业可能无法完成，或者可能无法一致地更新所有表。 例如，如果备份从内容数据库与 SharePoint 计时器作业同时SQL Server运行，则作业不会继续。
完成更新统计信息的 SharePoint 计时器作业后，可能会将以下事件写入 ULS 日志：
- e9bf“更新数据库中的统计信息时出错， {0}”
- cm1y “正在更新数据库中的统计信息， {0}”
- dbl2“跳过数据库的 {0} 统计信息更新，因为它的状态为 {1}”
- cm1x “正在更新所有数据库中的统计信息”{0}
如果未密切监视这些条件，并且未采取纠正措施，则数据库统计信息将过时，并且最终会发生 SharePoint 性能问题。
解决方案
为了防止这些症状和潜在的服务中断，应实施SQL Server维护计划，以便通过使用 FULLSCAN 选项来更新 SharePoint 内容数据库统计信息。 有关详细信息，请参阅 索引统计信息。
实现SQL Server维护计划以更新 SharePoint 数据库中的统计信息时，不需要从 SharePoint 禁用作业。 但是，由于这些维护任务从这两个位置执行类似的功能，因此，如果数据库由 SQL 管理，则允许从 SharePoint 场禁用“SharePoint 使用的数据库具有过时的索引统计信息”Heath Analyzer 规则。 有关如何从 SharePoint Server 管理索引更新作业的详细信息，请参阅 SharePoint 使用的数据库具有过时的索引统计信息 (SharePoint 2013) 。
更多信息
建议的最佳做法是，使用 FULLSCAN 选项每天从SQL Server更新 SharePoint 内容数据库的统计信息。 有关详细信息，请参阅 SharePoint Server 场中SQL Server的最佳做法和 SharePoint Foundation 2010 的数据库维护。
但是，如果 SharePoint 场当前由于过时的 STATS 而遇到性能问题，则可以将以下信息用作一次性缓解步骤来缓解此问题。
若要显示特定数据库中的数据库统计信息，请运行以下查询：
-- Checking the DB Stats
select a.id as 'ObjectID', isnull(a.name,'Heap') as 'IndexName', b.name as 'TableName',
stats_date (id,indid) as stats_last_updated_time
from sys.sysindexes as a
inner join sys.objects as b
on a.id = b.object_id
where b.type = 'U'
有关数据库统计信息评审的详细信息，请参阅 DBCC SHOW_STATISTICS。
若要更新使用 FULLSCAN 选项的单一数据库的数据库统计信息，请运行以下查询：
-- Update DB Stats
EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'
重要说明“sp_MSforeachtable”选项是“按原样”提供的未记录过程，仅用于缓解当前问题。 建议不要将此过程用作常规维护计划的一部分。 相反，请参阅我们的 UPDATE STATISTICS (Transact-SQL) 文档，了解如何使用 FULLSCAN 选项实现更新统计信息的计划。
根据数据库统计信息的过时程度，可能需要在更新数据库统计信息后运行 DBCC FREEPROCCACHE 命令来清除查询计划缓存。 可以在 DBCC FREEPROCCACHE (Transact-SQL) 中找到此过程的语法和参数。 这样做可确保新查询在更新数据库统计信息后使用最佳执行计划。 例如，请参阅以下查询：
-- Remove all elements from the plan cache
DBCC FREEPROCCACHE
重要
运行 DBCC FREEPROCCACHE 命令会清除 SQL 实例中所有查询计划的缓存。 在生产时段执行此命令之前，应充分理解此命令。
如果在更新过时的数据库统计信息后未执行 DBCC FREEPROCCACHE 命令，则具有低效执行计划的查询可能仍驻留在缓存中并使用。 如果是这种情况，请使用存储过程强制对指定的存储过程进行重新编译， (请参阅 sp_recompile (Transact-SQL) ) 。 例如，请参阅以下查询：
USE SP2013_Content_DB
GO
sp_recompile proc_getwebnavstruct
将 sp_recompile 命令与过程、函数或表参数一起运行，以缓存中的单个元素为目标进行删除，而不会影响实例。
仍然需要帮助？ 请转到 SharePoint 社区。