Natalia Asked: 2013-09-28 20:01:45 +0800 CST2013-09-28 20:01:45 +0800 CST 2013-09-28 20:01:45 +0800 CST 清理数据缓存是否有助于解决编译器内存压力？ 772 我目前遇到 RESOURCE_SEMAPHORE_QUERY_COMPILE 等待导致 CPU 峰值 100%，持续 10-20 分钟，只有在完全停止流量时才会消失。我认为这可能是内存压力，想知道减小索引大小是否有助于缓解内存压力。 sql-server sql-server-2008-r2 1 个回答 Voted Best Answer Thomas Stringer 2013-10-21T06:55:46+08:002013-10-21T06:55:46+08:00 查看MSDN 上关于sys.dm_os_wait_stats. 以下是上述参考资料中有关的引述RESOURCE_SEMAPHORE_QUERY_COMPILE： 当并发查询编译数达到限制时发生。高等待和等待时间可能表示过度编译、重新编译或无法缓存的计划。 如上所述，这种等待类型来自一次发生的太多编译。听起来像什么，如果您一直看到这种等待类型（不同于从冷计划缓存中等待），那么您的临时工作负载太高了。换句话说，您可能遇到计划重用不足的问题（一堆未参数化/准备好的计划，或者没有使用存储过程，因此出现了一个新的临时查询，因为没有可以重用的计划会编译一个新的）。 如果确实如此，有几种方法可以解决这个问题。 解决这个问题的真正方法是确保使用准备好的计划和存储过程。一种蛮力方法是将数据库设置为使用强制参数化。我会将后者作为最后的手段，因为强制参数化可能会有一些缺点。 有几种方法可以关注您的计划重用情况。最简单的（在我看来）是为实例捕获一些性能计数器： \SQLServer:SQL Statistics\Batch Requests/sec \SQLServer:SQL Statistics\SQL Compilations/sec \SQLServer:SQL Statistics\SQL Re-Compilations/sec 这是一个很好的经验法则，每秒编译量不应超过每秒批处理请求的 10%，每秒重新编译量不应超过每秒编译量的 10%。在对计划缓存重用进行故障排除时，我通常会从那里开始。随时监控这些计数器，并将结果发布在您的问题中，我可以帮助解释。 并回答您的直接问题，不减少索引大小或清除数据缓存不会缓解您的问题。
查看MSDN 上关于
sys.dm_os_wait_stats. 以下是上述参考资料中有关的引述RESOURCE_SEMAPHORE_QUERY_COMPILE：如上所述，这种等待类型来自一次发生的太多编译。听起来像什么，如果您一直看到这种等待类型（不同于从冷计划缓存中等待），那么您的临时工作负载太高了。换句话说，您可能遇到计划重用不足的问题（一堆未参数化/准备好的计划，或者没有使用存储过程，因此出现了一个新的临时查询，因为没有可以重用的计划会编译一个新的）。
如果确实如此，有几种方法可以解决这个问题。 解决这个问题的真正方法是确保使用准备好的计划和存储过程。一种蛮力方法是将数据库设置为使用强制参数化。我会将后者作为最后的手段，因为强制参数化可能会有一些缺点。
有几种方法可以关注您的计划重用情况。最简单的（在我看来）是为实例捕获一些性能计数器：
这是一个很好的经验法则，每秒编译量不应超过每秒批处理请求的 10%，每秒重新编译量不应超过每秒编译量的 10%。在对计划缓存重用进行故障排除时，我通常会从那里开始。随时监控这些计数器，并将结果发布在您的问题中，我可以帮助解释。
并回答您的直接问题，不减少索引大小或清除数据缓存不会缓解您的问题。