Server 2008，cpu 100%直到重新创建索引
我有一个4000000行表( Server 2008)。此表有一个由两个int列组成的私钥。一个对应于同一数据库的另一个表中的PK。他们之间有一种联系。另一个到另一个数据库中的一个表的PK。(我不知道这是否重要)
有时，查询的数量与通常情况相同，但CPU的使用率增加到90%-100%。而且这个表上的某些存储过程太长了。此时，只需选择在此表上运行的查询即可。
如果我等待，CPU的使用将在1或2个小时后恢复正常。但我也可以删除并重新创建PK索引。CPU的使用立即恢复正常。所以我认为这个问题与这个指数有关。我错了吗？
但该指数并不是零碎的。我每天晚上都要按维修计划重建。在每次大的插入或删除操作之后，我甚至尝试重新组织它。我还试图更新它的统计数据。我也试图什么也不做。
我每天都随机地得到这个问题，但在不同的时间，没有办法重现它。所以我不知道如何比较执行计划。
谢谢,
洛奇
编辑:此表由SSIS包填充。它插入缺失的行并删除不推荐的行(不更新)。插入是通过在每批限制为500行的oledb目的地内快速加载完成的。它可以进行批量插入。我尝试在这个包的末尾添加一些内容，包括重新组织索引和更新统计信息。
此问题在此SSIS包的执行过程中不发生。例如，它可能在结束后15分钟。它可以发生，即使有几行操作的包(例如50行)。
回答 2
Database Administration用户
发布于 2012-03-16 06:08:55
我的直觉猜测是，在重新创建PK之后CPU使用率下降是巧合，特别是因为您认为索引不是零碎的。我猜这个指数本身没有什么问题。更有可能的是，缺少满足针对该表执行的特定查询/proc的索引。
您需要做的是监视服务器。这是2008年，所以你有很多可用的工具，你可以用几种不同的方式来做。
听起来这种情况在一天中经常发生，因此观察Profiler跟踪并在CPU上排序是识别特定时刻的查询/进程对CPU造成影响的最快方法。(SQL是Profiler的服务器端版本--如果需要跟踪很长一段时间，这可能是一个更好的选择，但这是一个不同的对话。)
按照同样的思路，稍微准确一点，就是将Perfmon跟踪与Profiler跟踪关联起来，然后您就可以准确地看到CPU启动时运行的内容。(你可以在谷歌上搜索指令。)
另一种方法是查看执行DMV(参见下面的链接)，并在total_worker_time上进行排序，因为这与CPU成本有关。
这些方法将缩小您需要关注的查询/过程的范围，从这里您需要查看扩展计划，并确定是否可以添加索引、将查询分解为更小的部分，等等。
以下是一些让您入门的链接：
Database Administration用户
发布于 2012-03-17 23:34:56
如果在我看来，您的统计数据已经过时了，这将导致Server使用糟糕的执行计划来获取数据。您能发布执行计划吗?查询何时运行良好，何时运行不佳？
由于表中有4M行，所以统计数据在插入/更新/删除大约800,500行之前不会自动更新，因此，如果您输入600 k行，统计数据将保持不变，执行计划将不再适合当前的数据分发。
通过删除索引并重新创建它，您将有效地更新统计信息。
下一次出现问题时，尝试使用UPDATE statistics语句手动更新统计信息，看看这是否有效。如果是这样的话，这就是问题所在，您需要研究如何编写一个定期更新统计数据的作业。
https://dba.stackexchange.com/questions/15164
复制
相似问题
在Android中有没有什么简单、通用的方法来获取布局的根视图？
有没有一种通用的方法来知道用户是否在按住CTRL键？
有没有更通用的方法来声明这个数组？
有没有一种通用的方法来打印变量？
有没有更系统的方法来填充我的布局？
腾讯云开发者
