我想收到关于以下主题的build议。
通过我们公司的产品之一，我们“连接”到客户端的现有数据库，并将订单导入到我们自己的SQL Server中，以便让我们的桌面产品计划，并针对不同的货车进行优化， A到B.在导入过程中，我们遇到了一些可以通过以下方式解决的性能问题：
除此之外，我不得不说，我接pipe了在我之前在这家公司工作的另一个人的责任，那就是偶然的DBA，但现在是我的工作:-)
我们已经build立了几个维护计划（从我学到的东西并不总是最好的方法，我们现在正在遵循Ola Hallengren的维护解决scheme）来重build索引并更新统计数据。 但性能问题仍然存在。
以前的DBA试图诊断SQL Server上发生的事情，他使用了这个脚本：
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED SELECT 'Identify what is causing the waits.' AS [Step01]; SELECT TOP 10 [Wait type] = wait_type, [Wait time (s)] = wait_time_ms / 1000, [% waiting] = CONVERT(DECIMAL(12,2), wait_time_ms * 100.0 / SUM(wait_time_ms) OVER()) FROM sys.dm_os_wait_stats WHERE wait_type NOT LIKE '%SLEEP%' ORDER BY wait_time_ms DESC; 他发现CXPACKET比较高。
他search了一下，发现MAXDOP参数与它有关。 所以他们去了SSMS，把MAXDOP从一个值“0”改成了另一个值“1”，反之亦然。 一旦参数被改变（不pipe哪个方向），性能立即变好。 在切换参数之前，CPU非常高（在产品中工作几乎是不可能的），在切换之后立即使CPU使用率降至最低。 它看起来像SQL Server是无聊的死亡。
如果我们的人尝试将MAXDOP切换到每个脚本的其他值：
EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE GO EXEC sys.sp_configure N'max degree of parallelism', N'1' GO RECONFIGURE WITH OVERRIDE GO EXEC sys.sp_configure N'show advanced options', N'0' RECONFIGURE WITH OVERRIDE GO
令人惊讶的是根本没有任何效果。 CPU使用率与执行脚本之前一样高。
我对你们的问题是：
你有什么线索为什么在SSMS中切换MAXDOP使CPU使用率下降到正常值？
我知道我不能指望一个完全令人满意的答案，因为我的故事的细节不够详细。 但是，如果你能指出我正确的方向，比如嘿，看看I / O，像这样设置你的PerfMon等，我将不胜感激。
先谢谢你了，克里斯多弗
发生这种变化时发生了一些事情。
当这个改变使得SQL Server从计划caching中过期了所有的执行计划。 发生这种情况时，每个正在运行的查询都必须生成新的计划。
当您将MAXDOP设置从0更改为1时，这只会阻止SQL Server使用并行执行计划。 并行计划意味着SQL Server可以将所有处理器用于单个查询。 当您将此设置设置为1时，意味着每个查询只能使用一个线程。
CX_PACKET等待types意味着一个并行查询的一个线程正在等待该并行查询的另一个线程完成。 CX_PACKET是一个症状不是原因。
要确定根本原因，您需要查看问题查询的执行计划，并查看问题所在。 你可能有索引缺失，你可能有过时的统计数据，你可能需要更多的内存，你可以有缓慢的硬盘等。
根据我的经验，对于年轻的DBA来说，CXPACKET一直是棘手的等待types，往往会导致一些可预见的错误反应。 我已经尝试在SQL Server文章CXPACKET等待types疑难解答目前大多数高CXPACKET的原因，但也解释了CXPACKET背景
所以对于那些不想了解细节的人，我会在这里发表文章的总结：
不要将MAXDOP设置为1，因为这永远不是解决scheme
调查查询和CXPACKET历史来了解并确定它是否发生过一次或两次，
因为它通常只是系统中的例外
正常工作检查查询使用的表的索引和统计信息，并确保它们是最新的
检查并行度的成本阈值（CTFP），并确保使用的值适合您的系统
检查CXPACKET是否伴随LATCH_XX（可能还有PAGEIOLATCH_XX或SOS_SCHEDULER_YIELD）。 如果这是
应该降低MAXDOP的值，以适应您的硬件检查CXPACKET是否附有LCK_M_XX（通常伴随着IO_COMPLETION和ASYNC_IO_COMPLETION）。 如果是这样
这样的话，并行性并不是瓶颈。 解决这些问题
等待统计数据find问题和解决scheme的根本原因