Question

我们有一个有点复杂的SQL更新查询，每月运行几次。它大部分时间似乎运行得非常快，但在某些数据库上，它需要很长时间。在所涉及的表上运行“UPDATE STATISTICS”后，更新会立即再次快速运行。我们最终设置了一个夜间任务，它在数据库中的所有表上调用UPDATE STATISTICS。但这似乎没有解决问题。我们最终还是必须每次手动运行“UPDATE STATISTICS”。为什么统计数据会如此迅速地过时？

以下是查询的大致内容：

UPDATE DataTableA
SET DataTableA.IndexedColumn1 = 123456789, DataTableA.Flag1 = 1
FROM DataTableA WITH (INDEX(IX_DataTableA))
INNER JOIN GroupingTableA ON GroupingTableA.ForeignKey1 = GroupingTableA.PrimaryKey
INNER JOIN LookupTableA ON DataTableA.ForeignKey3 = LookupTableA.PrimaryKey
LEFT OUTER JOIN GroupingTableB ON DataTableA.IndexedColumn2 = GroupingTableB.IndexedColumn2
WHERE GroupingTableB.IndexedColumn1 = 123456789
AND DataTableA.IndexedColumn1 IS NULL
AND DataTableA.IndexedColumn2 IN ( ... 300 entries here ... )
AND DataTableA.Deleted = 0
AND GroupingTableA.Date <= GroupingTableB.EndDate
AND GroupingTableA.Date >= DATEADD(month, -1, GroupingTableB.StartDate)
AND LookupTableA.Column2 = 1
AND DataTableA.Status1 IN (1, 3)
AND DataTableA.Status2 NOT IN (1, 3, 9)

DataTableA包含数百万行 GroupingTableA和GroupingTableB每行包含数万行 LookupTableA包含几十行索引IX_DataTableA是（IndexedColumn1 ASC，IndexedColumn2 ASC）的索引

Answer 1

如果您强制使用特定索引（WITH (INDEX(IX_DataTableA))

，我认为您的统计数据不会那么重要

你确定你比优化器更了解吗？

我首先看一下快速更新和慢速更新的执行计划。此外，更新的记录数量是否与快速/慢速查询相当？

Answer 2

当自动统计信息开启时，引擎希望更新统计信息quite often，通常比夜间更新：

 Table Type | Empty Condition | Threshold When Empty |Threshold When Not Empty 
_________________________________________________________________________________
 Permanent  | < 500 rows      | # of Changes >= 500  | # of Changes >= 500 + (20% of Cardinality)
___________________________________________________________________________
 Temporary  | < 6 rows        | # of Changes >= 6    | # of Changes >= 500 + (20% of Cardinality)

但为什么不拿出猜测并简单地部署计划指南？请参阅Understanding Plan Guides。

为什么统计数据在SQL Server中如此快速地过时？

2 个答案: