在SQL Server 2014上具有完全扫描的更新统计信息使用100％cpu，在2008 R2上为15％

为什么对于具有相同硬件功能的相同表，全扫描更新统计信息在SQL Server 2014上可能使用20％的CPU，而在SQL Server 2014上却使用100％的CPU？

我一直在寻找MAXDOP，其他选项，但实际上看不到任何脱颖而出的东西。我意识到可能存在可能导致这种情况的设置，但是两个数据库的设置都非常相似（例如，两个数据库的设置均为MAXDOP4，并且两个数据库都有多个内核）。两者都是企业版。

SQL Server 2014与SQL Server 2008 R2中是否有某些“不同之处”可以解释这一点？两台服务器的内存选项均为90％。对寻找什么有任何想法吗？

我每周在使用SQL Server 2008 R2 / SP3和SQL Server 2014 / SP2的两台服务器上以完整（100％）扫描运行更新统计信息，并且数据库具有相同的结构。在2008 R2服务器上，两个非常大的表的更新状态需要花费几个小时，这是我期望的，但是CPU始终保持在20％左右的利用率以下。但是，在2014年服务器上，CPU会在100％的时间内运行40分钟。这些表格在2014服务器上要小一些。我通过使用SQL Monitor分析菜单看到了这一点。

这是2014 SQL Server上Ola日志文件的输出，CPU从大约2:10到2:45达到100％：

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  

Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

以下是上述两个统计信息在2008 R2 SQL Server上Ola日志文件的输出，但是CPU可能达到15％：

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  

Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

我无法使用服务器maxdop = 1来运行它们，因为这样会消除所有并行计划的生成，并且可能会损害应用程序。我计划朝相反的方向增加到8个（盒子上有16个核），然后看看会发生什么。可能会加快速度以减少固定CPU的时间。在大多数用户不在的情况下运行此作业。

根据SQL Server中的许多不同选项，统计信息更新可以并行进行：

• 并行性的成本阈值 -要使用并行性火车，查询必须很高。您的两台服务器可能具有不同的CTFP设置，导致2008R2更新成为单线程，而2014则可能成为多线程。
• 最大并行度 -指示如果SQL Server决定将查询并行化至多，则查询最多可以使用多少个内核。2008R2框可能会将MAXD​​OP设置为1，而2014框可能会将其设置为默认值0（无限制）。
• 资源调控器-此企业版功能使您可以将不同组的用户或应用程序限制为不同的MAXDOP。

在更高版本的SQL Server（2016及更高版本）中，这变得更加复杂：

• 数据库级别的作用域选项 -您可以右键单击数据库，进入属性，然后为该数据库设置MAXDOP级别。
• 统计信息并行提示 -从2016 SP2开始，统计信息创建和更新语句接受MAXDOP提示

正如您所指出的，您的2008R2是单线程的，而2014R是多线程的（因此，完成速度更快，但在运行时将CPU最大化）。

要为您的统计工作找到合适的平衡，请考虑以下事项：

• 数据库中同时还发生了哪些其他工作负载？您能否在短期内担当主导角色？例如，在大多数周末时间都处于空闲状态的数据仓库中，我看到人们在不知道反正使用服务器的情况下，会使用全扫描来努力处理统计信息更新。在重型交易环境中，即使用户在午夜时分抱怨，也必须开始减少对维护任务的影响。
• 全扫描真的必要吗？您是否在使用fullscan选项时看到只会得到好的计划的查询，或者只是将其作为最佳实践而已？随着数据库的增长，如果您的硬件投资跟不上速度，则可能必须开始在统计数据采样中权衡取舍，而不是进行全面扫描。
• 您可以不经常更新统计信息吗？例如，每个周末更新1/4的统计信息，然后每个月更新一次，一切都会更新统计信息吗？
• 您可以更新较少的对象吗？我经常看到人们甚至在巨大的审计或存档表上更新统计信息，仅仅是因为做了几十个新的插入操作，但是这些插入操作实际上并没有影响表上的统计信息（无论如何也没有人查询它）。

_{社区Wiki答案：}

最佳猜测：2014统计表上选择的更新统计数据的计划与2008 R2统计表上的统计数据平行，或更平行。

并行更新统计信息fullscan自2005年以来一直存在，有关从2016年开始的示例统计信息，请参阅SQL Server数据库引擎博客上的Gjorgji Gjeorgjievski撰写的SQL Server 2016中的查询优化程序添加。

如果您拥有Enterprise Edition，则可以使用资源调控器来限制维护作业使用的CPU。

还可以考虑为Javier Villegas的“ 更新建议”中的“连接建议” 添加MAXDOP参数投票。

相关问答：并行统计信息更新