Question

我在2013年看到了一个类似的问题，但没有回答，所以我发布了我的版本。

我们正在使用SQL Server 2008（SP4） - 10.0.6000.29（X64），并且拥有一个大约70GB的数据库，大约有350个表。每天只会发生少量更新，但每年有几次我们会将相当数量的数据转储到其中。有几种Windows服务不断查询数据库，但很少更新它。还有几个网站使用它和桌面应用程序（再次，每日最新更新）。

我们遇到的问题是，每隔一段时间，一次点击特定记录的查询将花费比平时更长的时间。以下是一个虚假的例子：

对于总记录少于600条的2个表的查询可能需要30秒以上：

select * 
from our_program_access bpa
join our_user u on u.user_id = bpa.user_id
where u.user_id = 50 and program_name = 'SomeApp'

但是当你将user_id值更改为另一个用户记录时，只需不到一秒钟：

select * 
from our_program_access bpa
join our_user u on u.user_id = bpa.user_id
where u.user_id = 51 and program_name = 'SomeApp'

正在使用的真实查询稍微复杂一点，但想法是相同的：搜索ID 50需要30秒以上，搜索ID 51需要＆lt; 1秒钟，但两者总共只返回1记录。

我们发现问题似乎与统计数据有关。出现此问题时，我们运行sp_updatestats，并且所有查询都是相等且快速的。所以，我们每晚都开始在维护计划中运行sp_updatestats。但问题仍然存在。我们还尝试设置AUTO_UPDATE_STATISTICS_ASYNC，但问题最终会出现。

虽然数据库很大，但它并没有真正经历巨大的变化，尽管它确实面临来自不同服务的不断查询。

同一台服务器上还有其他几个数据库，例如邮件日志，SharePoint和Web过滤。总的来说，在我们遇到这个问题之前，性能非常好。

在每天经历相对较小的更改的数据库上需要如此频繁地运行sp_updatstats是否有意义？我们还能做些什么来解决这个问题？

sp_updatestats临时修复了性能问题，尽管每天执行sp_updatestats

0 个答案: