如果你像我一样，那么你就会有一个在适当位置的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