UPDATE STATISTICS更新所有SQL Server数据库

核心提示：如果你像我一样，那么你就会有一个在适当位置的SQL Agent任务需要重建和重新组织，UPDATE STATISTICS更新所有SQL Server数据库，而实际上只有你数据库中的索引需要这样的操作，如果你依赖于Microsoft SQL Server中的标准技术维护计划，我可以向你保证，上面列出的每一个数据库都把AU

如果你像我一样，那么你就会有一个在适当位置的SQL Agent任务需要重建和重新组织，而实际上只有你数据库中的索引需要这样的操作。如果你依赖于Microsoft SQL Server中的标准技术维护计划，那么重建所有索引的焦土政策将产生。更确切地说，无论这些操作是否要求被用到具体的索引中，索引的重建以及对所有锁和日志的搅拌都会发生。这就是为什么可以说大多数人都会推出自己的索引维护解决方案。这也正是我最大的烦恼之一。无论如何，通过只维护成为碎片的索引，相对于你数据库中的表/索引，统计数据不能发生全面自动更新。我们所需要的正是对我们的SQL Server实例上的每一个数据库采取更新所有统计这样一个快速的解决方案。

在你开始操作前，我必须声明一个事实，那就是你在自己的数据库上有AUTO_UPDATE_STATISTICS ON，但请记住那并不意味着它们正在更新!

可能你对此会很不屑。那么请稍微思考这个问题。当处在下面的情况时，SQL Server的引擎将会自动更新：

l 当数据刚被添加到一张空表时

l 当统计是上次搜集的并且从搜集开始，统计数据对象的主要字段每500秒增长一次时，这张表的记录超过500。

l 当统计数据是上次搜集的，并且，从上次统计数据搜集日期起统计数据对象的主要字段按照每500秒加上行数的20%更改时。

在这个标准下，有很多这样的情况：当潜在的数据以这样一种方式或者层次变化时，存在于一个索引中的统计不能正确反映数据库中真实的数据。正因为如此，你不能仅仅依赖于引擎来使你的统计保持检查和更新成当前的状态。这是一个简单的代码块，它将迭代处理你的数据库以此来建立sp_updatestats命令，该命令随后将被复制粘贴到一个新的查询窗口来执行。这些代码将与所有当前的和先前的SQL Server版本一道回到SQL 7.0工作。

　　　DECLARE @SQL VARCHAR(1000)
　　DECLARE @DB sysname
　　DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR
　　SELECT [name]
　　FROM sys..sysdatabases
　　WHERE [name] NOT IN ('model', 'tempdb')
　　ORDER BY [name]
　　OPEN curDB
　　FETCH NEXT FROM curDB INTO @DB
　　WHILE @@FETCH_STATUS = 0
　　BEGIN
　　SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)
　　PRINT @SQL
　　FETCH NEXT FROM curDB INTO @DB
　　END
　　CLOSE curDB
　　DEALLOCATE curDB

在我的测试数据库中，这些代码产生了下面的结果：

图1

接下来我们把复制这个文本，把它粘贴到SQL Server管理套件的一个查询窗口，然后针对这个实例执行它。另一种方法是，你可以选择只针对select数据库执行它，但这完全取决于你。

　　　USE [Dummy]
　　EXEC sp_UpdateStats
　　USE [master]
　　EXEC sp_UpdateStats
　　USE [msdb]
　　EXEC sp_UpdateStats
　　USE [MSSQLTips]
　　EXEC sp_UpdateStats
　　USE [MSSQLTips_DUPE]
　　EXEC sp_UpdateStats
　　USE [Northwind]
　　EXEC sp_UpdateStats
　　USE [Sitka]
　　EXEC sp_UpdateStats
　　USE [Utility]
　　EXEC sp_UpdateStats

我已经提供了上面执行的SQL语句搜集产生的输出结果实例。正如你看到的，引擎仍然会审查这些统计，看看它们是否需要更新。它将忽略哪些可以接受的，只更新那些要求这种操作的统计。我可以向你保证，上面列出的每一个数据库都把AUTO_UPDATE_STATISTICS和AUTO_CREATE_STATISTICS设置成ON，但下面的结果表明统计数据将变成过时的。

图2