在检查性能问题时，我看到 CXPACKETS 的大量涌入，这表明我可能需要查看并行性和 MAXDOP 的成本阈值。
在对 MAXDOP 进行任何重大更改之前，我遵循了许多其他人的建议，包括 @mrdenny 在对 SQL Server 2008 的 CXPACKET 等待性能调整的回答中的建议和@aron-Bertrand 在处理 CXPACKET 等待中的回答- 设置成本阈值对于并行性。我已添加到维护中，以每晚完全更新统计数据。感觉这是一个明智的举动。
但是，对成本阈值进行修改仍然让我烦恼。
并行性的成本阈值应该在什么时候改变？有没有人有一个例子来说明（在检查了他们的查询和工作量的成本之后）他们对这个成本进行了更改？
如果这是在上一个问题中已回答的问题，请道歉。
谢谢！
我对使用 Waits 和 Queues 进行性能调整还很陌生 - 很吸引人，但也不总是那么直观......
现在，我的一个客户有一个 SQL Server 2008 64 位企业版，目前分配给它 16 GB 的 RAM，在具有 64 GB RAM 的物理服务器上运行（在同一台上还有其他和更改的 SQL Server 实例）机）。
他正在运行的这个应用程序是一个 Sharepoint 2010 解决方案，在大多数情况下，它的性能 - 很好 - 对于 Sharepoint 站点来说还可以。除了搜索，这是非常缓慢的。
现在从 SQL Server 的角度来看，我已经观察了几天的等待统计数据，前三种等待类型是：
1) CXPACKET 约为 49%
2) SOS_SCHEDULER_YIELD 约为 10.5%
3) OLEDB 约为 9.5%
这似乎非常一致——随着时间的推移没有大的变化。
信号等待时间极短，所以这似乎并不表示 CPU 压力。那么是什么导致了这种模式——我们可以做些什么来 (a) 找到更多相关信息，或 (b) 找到加快速度的解决方案？
有什么想法吗？见解？想法？我对任何事情都持开放态度——我们不能改变的是基本架构（单独的 SQL Server 实例，在物理服务器之间移动——以及基于 Unix 的 SAN，它不能保证数据和登录到单独的物理磁盘上的分离）
再说一遍：这是一个SharePoint网站 …