标签: statistics

我有一个全文查询，它通常非常快，但当它导致统计更新时可能会超时，因为该数据库上的统计更新非常慢。通常，在更新统计信息后，查询会“恢复”到正常速度，但我见过查询总是超时的情况，我只能用统计信息从未更新的事实来解释（或者我认为是这样）。

不幸的是，我此时无法重现该问题，因为我们将统计更新切换为“异步自动更新统计”以防止超时发生（稍微过时的统计信息对我们来说不是问题）。

所以我的问题是

如果将统计更新设置为（默认）同步统计更新（异步自动更新统计 = false），是否可以保证在超时的查询上更新统计信息？

我发现了一个引用，否则说明- 如果是这种情况，我无法解释持续超时查询的情况。

我发现每天运行的大而讨厌的数据提取查询需要更新统计信息，以避免根据不正确的行数估计制定可怕的查询计划（让我们不必担心我的统计信息是否应该自动更新）。

如标题中所述，我的问题是：如果在更新给定的统计数据集之前准备好查询计划，而在优化器做出的决定结果出来的时候，我是否应该担心不正确的查询计划仍然存在？是错的？

或者统计更新自动导致依赖查询计划被刷新？

如果计划仍然存在，是否有办法确定哪些计划取决于给定索引的统计数据？（我知道，我可以去挖掘 DMV 文档，只是希望有人已经有了答案）

我正在尝试编写 T-SQL 脚本，它将：

A) 将数据库大小缩小到可能的最小大小；B) 进行完整性检查，彻底“重组”和优化数据库，使其处于“新鲜”状态。

这是我目前拥有的：

-- Check database integrity:

DBCC CHECKDB WITH NO_INFOMSGS;
GO

-- Get space usage information:

EXEC sp_spaceused @updateusage = N'TRUE';
GO

-- Shrink database:

DBCC SHRINKDATABASE (0, 0);
GO

-- Reindex all tables:

EXEC sp_msforeachtable N'PRINT ''Indexing table: ?''; DBCC DBREINDEX (''?'');'
GO

-- Update statistics for all tables:

EXEC sp_msforeachtable N'UPDATE STATISTICS ? WITH FULLSCAN'
GO

-- Clear procedure cache:

DBCC FREEPROCCACHE;
GO

-- Update all usage info in the database:

DBCC UPDATEUSAGE …

一些背景： 我有一个样本人口数据文件。数据文件中的每条记录都有一个频率权重（FIELD NAME: wgt），指示需要复制多少次记录才能获得真正的总体。数据在 Microsoft SQL 2008 R2 中设置。生成权重的频率分布以查看某种特定类型的记录是否以任何方式过度表示通常是一种很好的做法 - 从而帮助识别趋势/异常值。这个任务在 SQL 中很简单：

SELECT wgt, COUNT(*) FROM tablename 
GROUP BY wgt

挑战： 我想根据其他值进一步分离这些频率。假设不同家庭规模的权重频率分布。实现此目的的一种方法是在上述语句中使用不同的 where 条件：

SELECT wgt, COUNT(*) FROM tablename 
WHERE household_size=x --x being the desired segment
GROUP BY wgt

但是有没有办法用所有不同的段创建一个表？像这样的东西：

WGT |   SIZE1       SIZE2       SIZE3       SIZE4 
--------------------------------------------------
1   |    2,034      1,025       502         234 
2   |    215        253         142         23 
3   |    31         25          21          34 
4   |    7          1           3           7 
5   |    5          NULL        2           5 
6 …

是否可以使用 T-SQL 判断查询上次访问统计信息的时间？我试图确定查询中涉及哪些统计信息，我知道我可以检查可视化查询计划，但我想知道是否有一个表（或多个表）包含这些信息。

我试图更好地了解 SQL Server 如何使用远程 SQL Server（例如链接服务器）上的统计信息。我知道用户需要 db_owner/db_ddladmin 权限才能使用远程框上的统计信息。起初，根据 Microsoft 的以下文本，这似乎非常简单。

要在链接服务器上使用表时创建最佳查询计划，查询处理器必须具有来自链接服务器的数据分布统计信息。对表的任何列具有有限权限的用户可能没有足够的权限来获取所有有用的统计信息，并且可能会收到效率较低的查询计划并体验较差的性能。如果链接服务器是 SQL Server 的实例，要获取所有可用的统计信息，用户必须拥有该表或者是链接服务器上的 sysadmin 固定服务器角色、db_owner 固定数据库角色或 db_ddladmin 固定数据库角色的成员.

让我困惑的是“用户”这个词。我们为所有连接而不是用户登录使用标准安全上下文。此登录名/用户具有上述对相关数据库的定义所需的权限。此外，我们不使用模拟。

我曾尝试使用在删除服务器上具有和未具有提升权限的帐户运行查询并捕获两端的跟踪。在我看来，远程服务器不会收集统计信息，除非实际用户（键盘上的那个人）拥有提升的权限。我相信这是真的，因为当用户拥有所需的权限时，我只会看到对 sys.sp_table_statistics2_rowset 的调用。

我真的希望这是有道理的。

有没有人了解这在 SQL 2008 R2 及更低版本中的实际工作原理？

我对以下类型的 Oracle 11g 进行了查询，这导致了一系列非常低效的全表扫描：

select t.Id, t.ObjectId, t...[other Tasks columns]
    , od1...[ObjectData1 columns]
    , od2...[ObjectData2 columns]
from Tasks t
left join ObjectData1 od1 on t.ObjectId=od1.ObjectId
left join ObjectData2 od2 ...
... [more leftjoins] ...
where t.ObjectId = 12345
or t.Id in (
    select TaskId from ObjectAffectingTasks where ObjectId=12345
)

任务在 Id、ObjectId 上有索引；ObjectAffectingTasks在 ObjectId 和 TaskId 上都有索引。所有连接的表也有适当的索引。该ObjectAffectingTasks表包含任务ID影响的对象，但对象ID有另一个，所以影响对象ID为12345的所有任务应选择。

在分析查询时，似乎是 OR 条件破坏了执行计划。只有 ObjectId 或只有子查询的 where 子句使用了所有索引。另一种解决方法是创建一个 Union 子查询，它也使用索引：

where t.Id in (
    select TaskId from ObjectAffectingTasks where ObjectId=12345 …

当我尝试在文件流列上创建统计信息时，我收到以下错误消息：

表 'MyTable' 中的列 'MyColumn' 的类型不能用作索引或统计信息中的键列。

这记录在CREATE STATISTICS的 BOL 页面中，这不是问题。

但是，当我在列（IS NOT NULL, 为记录）上运行带有谓词的查询时，会自动创建统计信息。为什么手动创建不允许这样做，但自动创建仍然可以？

我想手动创建统计数据的原因是我想标记它NORECOMPUTE以避免扫描几GB的数据。我知道我可以让 SQL Server 自动创建它然后NORECOMPUTE稍后标记它，但是自动创建是使用默认示例触发的，我可以0 ROWS在手动创建中覆盖它。我也想知道这是否有原因。

我们最近从 SQL Server 2008R2 升级到 SQL Server 2014 SP1 + CU4。

几周后，执行计划出现了无法正确估计行数的问题。问题一度变得如此严重，以至于决定通过再次启用9481跟踪标志和更新统计信息来恢复到旧的基数估计器。当我说“变得如此糟糕”时，我指的是在某些情况下查询的执行时间增加了 10。

使用 traceflag 9481已经解决了问题，但这不是解决方案吗？

搜索谷歌显示，有些人采用旧的基数估计器路线，而其他人则使用2312和4199的组合来使用新的估计器。

那么在从 2008R2 升级到 2014 之后，我们应该采取什么样的跟踪标志（如果有）和其他步骤的组合？

谢谢，克雷格

4 月 26 日上午 9 点更新

4199 跟踪标志不会打开新的基数估算器。我不得不改用 2312 跟踪标志。

使用 4199 跟踪标志时，版本仍为70。Chris Wood 的回答让我想起了Brent Ozar的一篇文章，我在某个时候也读过。仍在等待查看执行时间是否有所改善。

在 SQL Server 2005 上工作时，我想使用数据库引擎优化顾问来帮助我优化我的网络服务器。

我做的第一件事是创建一个服务器端配置文件跟踪并运行它大约一个小时。

这是生成的跟踪文件。

当我在 DTA 上使用这个文件时，我得到以下建议：

建议翻译成下面的脚本，评论在那里，因为我仔细检查了索引建议。

CREATE STATISTICS [_dta_stat_2108846875_3_6] ON [dbo].[ProductBulletPoint]([LanguageId], [NoteTypeCode])


CREATE NONCLUSTERED INDEX [_dta_index_ProductBulletPoint_39_2108846875__K6_K1_K3_2_4_5_7] ON [dbo].[ProductBulletPoint] 
(
    [NoteTypeCode] ASC,
    [Tier1] ASC,
    [LanguageId] ASC
)
INCLUDE ( [SeasonItemId],
[SortOrder],
[NoteText],
[NoteGroup]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]


--SP_HELPINDEX9 'ProductBulletPoint'
-- the index [_dta_index_ProductBulletPoint_39_2108846875__K6_K1_K3_2_4_5_7]  is ok to implement

CREATE NONCLUSTERED INDEX [_dta_index_ProductShipTax_39_745366020__K7_K5_K2_K3_K1_K4_6] ON [dbo].[ProductShipTax] 
(
    [TaxRegionId] ASC,
    [ItemNo] ASC,
    [DateFrom] ASC,
    [DateTo] …