我对 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%
这似乎非常一致——随着时间的推移没有大的变化。
- PAGEIOLATCH_SH 排在第七位 - 占总等待时间的 2.5%，平均资源等待时间为 14 毫秒。
- ASYNC_IO_COMPLETION 排在八位——不到总等待时间的 2%，但平均资源等待时间高达 38 秒（是的，秒——不是毫秒！）
信号等待时间极短，因此这似乎并不表示 CPU 压力。那么是什么导致了这种模式 - 我们可以做些什么来 (a) 找到更多相关信息，或 (b) 找到加快速度的解决方案？
有什么想法吗？见解？想法？我对任何事情都持开放态度——我们不能改变的是基本架构（单独的 SQL Server 实例，在物理服务器之间移动——以及基于 Unix 的 SAN，它不能保证数据分离并登录到单独的物理磁盘上）
再次说明：这是一个SharePoint站点 - 据我所知，尝试通过索引或重构数据库来解决问题是困难和不可能的。
由于这是 SharePoint，您的双手被束缚了。如果不失去 Microsoft 的支持，您将无法创建索引或统计信息。
CXPACKET 只是意味着并行查询的一个线程正在等待另一个线程完成等待其他事情。SOS_SCHEDULER_YIELD 可能意味着一些事情，通常它意味着你需要修复你的索引，你有没有正确调整的查询，所以 SQL Server 正在暂停这些查询（产生它们）以便它可以处理其他东西（因为这个是 SharePoint，您对此无能为力）。OLEDB 意味着 SQL Server 正在等待 OLEDB 驱动程序，因此可能有链接服务器查询或类似的东西正在调用另一个数据库服务器。你也无能为力。
听起来，如果不投入更多硬件来解决这个问题，你几乎无能为力。使用探查器、服务器端跟踪或扩展事件，找到运行时间过长的查询，检查它们的执行计划，看看它们有多糟糕。奇怪的是那些搜索查询正在执行大型扫描操作。
内容数据库有多大？Microsoft 建议将内容数据库保持在 100 Gig 以下，以便将扫描保持在最低限度。