Questions tagged «statistics»

用于查询优化的统计信息是包含有关表或索引视图的一个或多个列中值分布的统计信息的对象。

1
直方图以外的基数估计
设定 我在了解基数估算值时遇到了一些麻烦。这是我的测试设置： 2010版本的Stack Overflow数据库 SQL Server 2017 CU15 + GDR（KB4505225）-14.0.3192.2 新CE（兼容级别140） 我有这个过程： USE StackOverflow2010; GO CREATE OR ALTER PROCEDURE #sp_PostsByCommentCount @CommentCount int AS BEGIN SELECT * FROM dbo.Posts p WHERE p.CommentCount = @CommentCount OPTION (RECOMPILE); END; GO dbo.Posts表上没有非聚集索引或统计信息（上有聚集索引Id）。 当要求为此的估计计划时，出来的“估计行” dbo.Posts为1,934.99： EXEC #sp_PostsByCommentCount @CommentCount = 51; 当我要求估算的计划时，会自动创建以下统计信息对象： DBCC SHOW_STATISTICS('dbo.Posts', [_WA_Sys_00000006_0519C6AF]); 其中的重点是： …
1
SQL Server每天重新创建计划
我们的生产环境中存在这个问题。 Windows NT 6.1（内部版本7601：Service Pack 1）上的Microsoft SQL Server 2008 R2（SP1）-10.50.2500.0（X64）-企业版（64位）。 SQL Server将删除所有（几乎100％）旧的执行计划，并每天隔夜（从11:00 PM到8:00 AM）重新创建它们。当“自动更新统计信息”处于禁用状态时，甚至会发生这种情况。我们已在过去2-3周内启用了“自动更新统计信息”。但它仍在发生。 我们真的不知道是什么触发了计划的重新生成，但是我们确信我们不会手动进行。 与重新生成计划的时间真正吻合的唯一一件事是我们拥有的DB​​维护工作：每日索引重组（当碎片为5-30％时）和每日索引重建（当碎片大于30％时） ）的工作。通常，此日常维护工作仅会进行重组（因为索引碎片每天都不会超过30％）。 影响： 这些新创建的计划使一些UDF调用/查询调用（从UI /网页调用）花费的时间更长（几分钟而不是不到1秒），因此会话堆积如山，使CPU接近90％ 。 当这些卡住的会话被强制删除（在DB端）时，问题消失了； 1）当手动清除了所有相应的执行计划（对于查询）时，或者2）当UDF改变了（对于功能）时，问题就消失了。从那时起，SQL Server创建的任何新计划都可以在一整天内完美运行，直到第二天早上出现相同问题为止。同样，这种行为也不是100％一致的，我们并不是每天早上都真正看到它。但是，在一段时间内，我们连续4-5天一直在观察它。 问题似乎发生在工作时间早晨，即在更密集地访问UI /网页时。 有谁知道这是什么原因以及如何解决这个问题的线索？任何帮助将非常感激。
2
stats_column_id和index_column_id不会随着聚集索引的物理顺序更改而更新
除非我对列的用途有误解，否则以下代码指示更改聚集索引的结构不会更改sys.stats_columns DMV中stats_column_id列的顺序位置（）。（在AdventureWorks2014和AdventureWorks2008R2中测试） select i.name, c.name, ic.column_id, ic.index_column_id from sys.indexes i join sys.index_columns ic on i.object_id = ic.object_id and i.index_id = ic.index_id join sys.columns c on i.object_id = c.object_id and ic.column_id = c.column_id where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID' order by ic.key_ordinal; select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id from sys.stats s join sys.stats_columns …
3
并行统计更新
在SQL Server 2008或更高版本中，是UPDATE STATISTICS WITH FULLSCAN单线程操作还是可以使用并行性？如何使用默认采样更新统计信息-它可以使用并行性吗？我没有看到指定MAXDOP更新统计信息的选项。
1
为什么SQL Server拒绝使用Fullscan以外的任何内容来更新这些统计信息？
我注意到在每日数据仓库构建中，运行时间相对较长（超过20分钟）的自动更新统计信息操作。涉及的表是 CREATE TABLE [dbo].[factWebAnalytics]( [WebAnalyticsId] [bigint] IDENTITY(1,1) NOT NULL, [MarketKey] [int] NOT NULL CONSTRAINT [DF_factWebAnalytics_MarketKey] DEFAULT ((-1)), /*Other columns removed*/ CONSTRAINT [PK_factWebAnalytics] PRIMARY KEY CLUSTERED ( [MarketKey] ASC, [WebAnalyticsId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [MarketKeyPS]([MarketKey]) ) ON …
1
统计。多列直方图可能吗？
我正在考虑以下情况：我有两根高密度色谱柱，但这些色谱柱不是独立的。 定义 这是我出于测试目的而创建的表的定义。 CREATE TABLE [dbo].[StatsTest]( [col1] [int] NOT NULL, --can take values 1 and 2 only [col2] [int] NOT NULL, --can take integer values from 1 to 4 only [col3] [int] NOT NULL, --integer. it has not relevance just to ensure that each row is different [col4] AS ((10)*[col1]+[col2]) …
1
统计信息是最新的，但估计不正确
当我这样做时dbcc show_statistics ('Reports_Documents', PK_Reports_Documents)，报告ID 18698会得到以下结果： 对于此查询： SELECT * FROM Reports_Documents WHERE ReportID = 18698 option (recompile) 我得到一个查询计划，该计划使聚簇索引PK_Reports_Documents按预期进行。 但是令我感到困惑的是估计行数的错误值： 根据此： 当示例查询WHERE子句值等于直方图RANGE_HI_KEY值时，SQL Server将使用直方图中的EQ_ROWS列来确定等于的行数。 这也是我期望的样子，但是在现实生活中情况并非如此。我还尝试RANGE_HI_KEY了由提供的直方图中存在的其他一些值，show_statistics并经历了相同的情况。就我而言，此问题似乎导致某些查询使用非常不理想的执行计划，导致执行时间为几分钟，而我可以通过查询提示使其在1秒内运行。 总而言之：有人可以解释一下为什么EQ_ROWS直方图中的行数不用于估计行数以及不正确的估计值来自何处吗？ 更多（可能有帮助）的信息： 自动创建统计信息已打开，并且所有统计信息都是最新的。 正在查询的表大约有8000万行。 PK_Reports_Documents是由ReportID INT和组成的组合PKDocumentID CHAR(8) 该查询似乎总共加载了5个不同的统计对象，所有这些对象都包含ReportID+表中的其他一些列。它们都已全新更新。RANGE_HI_KEY下表中的是直方图中最高的上限列值。 +-------------------------------------------------------------------------+----------+--------------+--------------+---------------------+--------------+------------+----------+---------------------+----------------+ | name | stats_id | auto_created | user_created | Leading column Type | RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | …
1
我应该在数据仓库中禁用“自动更新统计信息”吗？
我在SQL Server中有200 GB的数据仓库。 对于某些查询，我的执行时间一直很慢；例如12个小时的简单delete查询inner join。 在对执行计划进行了一些研究之后，我使用该WITH FULLSCAN选项更新了查询中涉及的2个表的统计信息。 现在查询将在不到一秒钟的时间内执行，因此看来统计信息不是最新的。 我正在考虑禁用auto update statistics数据库，并UPDATE STATISTICS在加载数据仓库后手动运行。每天晚上，从源ERP系统增量加载数据仓库。 我假设auto update statistics在数据仓库场景中不是真的有用吗？相反，加载数据后手动更新统计信息是否更有意义？
1
为什么我的索引查找可以估计正确的行数而排序运算符不能呢？
我有一个查询，该查询在谓词上使用函数，如下所示： commentType = 'EL' AND commentDateTime >= DATEADD(month,datediff(month,0,getdate()) - 13,0) 我在commentType上有一个经过筛选的索引，该索引具有40K行，当我运行查询时，Index Seek的估计行数非常准确（大约11K），但是对于下一步（sort运算符），它完全忽略了统计信息，仅估算过滤索引中的总行数。 为什么会这样呢？我知道有关可保留性的基础知识，并且为了安全起见，我已经进行了测试，以实际日期（2014-01-01）替换dateadd和voila ...排序开始正确地猜测行数... 为什么会发生这种情况，我该如何解决？我无法通过固定日期...
2
了解统计信息，执行计划和“升序关键问题”
我试图更好地（从概念上）理解统计信息，执行计划，存储过程执行之间的关系。 我是否正确地说统计仅在为存储过程创建执行计划时使用，而没有在实际执行上下文中使用？换句话说，如果这是真的，那么一旦创建了计划（并假设其已正确使用），“最新”统计数据的重要性如何？ 我读过的一篇文章（《统计》，《行估计》和《升序的日期》栏）使我特别受启发，该文章描述了一种非常类似于我每天都使用客户数据库的情况。 在我们使用特定存储过程定期查询的最大表之一中，我们有一个升序的日期/时间列。 当每天增加十万行时，如何防止执行计划变得过时？ 如果我们经常更新统计信息以解决此问题，那么在此存储过程的查询中使用OPTION（RECOMPILE）提示是否有意义？ 任何意见或建议，将不胜感激。 更新：我正在使用SQL Server 2012（SP1）。
1
如何在统计中确定直方图的步数
如何在SQL Server的“统计信息”中确定直方图步数？ 为什么即使我的键列有200多个不同的值，它也限制为200步？有决定因素吗？ 演示版 模式定义 CREATE TABLE histogram_step ( id INT IDENTITY(1, 1), name VARCHAR(50), CONSTRAINT pk_histogram_step PRIMARY KEY (id) ) 在表中插入100条记录 INSERT INTO histogram_step (name) SELECT TOP 100 name FROM sys.syscolumns 更新和检查统计信息 UPDATE STATISTICS histogram_step WITH fullscan DBCC show_statistics('histogram_step', pk_histogram_step) 直方图步骤： +--------------+------------+---------+---------------------+----------------+ | RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | …
1
SQL Server中统计信息的默认样本大小是多少？
从MSDN： 如果(SAMPLE, FULLSCAN, RESAMPLE)未指定任何样本选项，则查询优化器默认对数据进行采样并计算样本大小。 如何确定统计数据的默认样本量？ 我经历了MSDN，但没有找到任何公式或方法来标识默认样本大小。到处都只有公式可以触发自动统计信息更新。任何指针都会有所帮助。
2
永不结束查询存储搜索
我从一开始说，我的问题/问题类似于此之前的一个，但因为我不知道的原因或起始信息是一样的，我决定后，我的问题有一些更多的细节。 当前问题： 在一个奇怪的时刻（工作日临近结束），生产实例开始出现异常行为： 实例的CPU较高（从约30％的基准开始，它增加了约一倍，并且仍在增长） 每秒增加的事务数（尽管应用程序负载未发生任何变化） 空闲会话数增加 从未显示此行为的会话之间发生奇怪的阻止事件（即使读取未提交的会话也导致了阻止） 等待间隔的最长时间是第一页上的非页面锁，第二名是锁 初步调查： 使用sp_whoIsActive，我们看到了由监视工具执行的查询决定运行速度非常慢，并占用大量CPU，这在以前是没有发生的。 隔离级别未提交； 我们查看了看到古怪数字的计划：StatementEstRows =“ 3.86846e + 010”，其中约150 TB的估计数据已返回 我们怀疑原因是监视工具的查询监视功能引起了，因此我们禁用了该功能（我们还与提供程序一起打开了一张票证，以检查他们是否知道任何问题） 从第一个事件开始，它又发生了几次，每次我们终止会话时，一切都恢复正常； 我们意识到查询极为相似的一个查询在BOL使用MS用于查询存储监测-查询，最近在性能倒退（在时间上比较不同点） 我们手动运行相同的查询并看到相同的行为（使用的CPU不断增加，闩锁等待时间增加，意外锁定等。） 有罪查询： Select qt.query_sql_text, q.query_id, qt.query_text_id, rs1.runtime_stats_id AS runtime_stats_id_1, interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), p1.plan_id AS plan_1, rs1.avg_duration AS avg_duration_1, rs2.avg_duration AS avg_duration_2, p2.plan_id AS plan_2, interval_2 = …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.