在运行我们的企业ERP（Dynamics AX 2012）时，我注意到我们的生产环境似乎比我们的开发系统慢得多。
在运行跟踪的同时在开发和生产环境中执行相同的活动后，我确认与开发相比，SQL查询在我们的生产环境中执行得非常慢（平均慢10到50倍）。
最初，我将其归因于负载，并在下班时间在生产环境上重新运行了相同的活动，并在跟踪中找到了相同的结果。
我在SQL Server中清除了等待统计信息，然后让服务器在其正常生产负载下运行了一段时间，然后运行了以下查询：
WITH [Waits] AS
(SELECT
[wait_type],
[wait_time_ms] / 1000.0 AS [WaitS],
([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
[signal_wait_time_ms] / 1000.0 AS [SignalS],
[waiting_tasks_count] AS [WaitCount],
100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
FROM sys.dm_os_wait_stats
WHERE [wait_type] NOT IN (
N'CLR_SEMAPHORE', N'LAZYWRITER_SLEEP',
N'RESOURCE_QUEUE', N'SQLTRACE_BUFFER_FLUSH',
N'SLEEP_TASK', N'SLEEP_SYSTEMTASK',
N'WAITFOR', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
N'XE_TIMER_EVENT', N'XE_DISPATCHER_JOIN',
N'LOGMGR_QUEUE', N'FT_IFTS_SCHEDULER_IDLE_WAIT',
N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
N'CLR_AUTO_EVENT', N'DISPATCHER_QUEUE_SEMAPHORE',
N'TRACEWRITE', N'XE_DISPATCHER_WAIT',
N'BROKER_TO_FLUSH', N'BROKER_EVENTHANDLER',
N'FT_IFTSHC_MUTEX', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'DIRTY_PAGE_POLL', N'SP_SERVER_DIAGNOSTICS_SLEEP')
)
SELECT
[W1].[wait_type] AS [WaitType],
CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S],
CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S],
CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S],
[W1].[WaitCount] AS [WaitCount],
CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage],
CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S],
CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S],
CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
[W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold我的结果如下：
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S
SOS_SCHEDULER_YIELD 4162.52 3.64 4158.88 4450085 77.33 0.0009 0.0000 0.0009
ASYNC_NETWORK_IO 457.98 331.59 126.39 351113 8.51 0.0013 0.0009 0.0004
PAGELATCH_EX 252.94 5.14 247.80 796348 4.70 0.0003 0.0000 0.0003
WRITELOG 166.01 48.01 118.00 302209 3.08 0.0005 0.0002 0.0004
LCK_M_U 145.47 145.45 0.02 123 2.70 1.1827 1.1825 0.0002
因此，到目前为止，似乎最大的Wait是SOS_Scheduler_Yield，我四处搜寻，发现通常与CPU无法跟上有关。
然后，我连续多次运行此查询。
SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255
我知道我应该在寻找具有非零runnable_tasks_count或pending_disk_io_count的调度程序，但是几乎所有时间它基本上都是零。
我还应该提到，最大并行度设置为1，因为Dynamics AX工作负载本质上通常是OLTP，并且将其更改为8并不会对上述等待状态产生太大的影响，它们几乎完全相同性能问题。
我有点无所适从，我基本上有一个SQL Server，看似CPU被束缚了，但不等待runnable_tasks或IO。
我确实知道此SQL Server的IO子系统不是很好，因为在包含实际数据库的驱动器上运行SQLIO可能会导致相当低的数字（对于某些类型的读/写，每秒要10MB），由于服务器上用于缓存大多数数据库的内存量，SQL似乎没有在等待它。
以下是一些环境信息以帮助您：
生产环境：
- SQL服务器
- 惠普ProLian DL360p Gen8
- 英特尔至强E5-2650 0 @ 2.00GHz x 2带超线程（32个逻辑内核）
- 184GB记忆体
- Windows Server 2012
- 2个SQL Server 2012 Standard实例（RTM，未修补）
- 突袭1 279GB驱动器（15k）C：驱动器，包含数据库和操作系统
- 不同的单独驱动器上的页面文件和TempDB（固态）
我的开发人员：
- Hyper-V托管的SQL Server和Dynamics AX 2012 AOS服务器
- 具有超线程功能的Core i7 3.4ghz（8个逻辑内核）
- 8GB内存
- Windows Server 2008 R2
- 整个VM的SSD。
我欢迎您寻求其他意见。