Questions tagged «index-statistics»

3
什么时候创建统计信息而不是创建索引更好？
我发现了很多有关什么 的信息STATISTICS：如何维护它们，如何从查询或索引手动或自动创建它们，等等。但是，我无法找到有关何时使用的任何指导或“最佳做法”信息创建它们：在什么情况下，手动创建的STATISTICS对象比从Index中受益更多。我已经看到了手动创建的筛选统计信息，可以帮助对分区表进行查询（因为为索引创建的统计信息涵盖整个表，而不是每个分区-太小了！），但是肯定还有其他情况可以从统计对象中受益不需要索引的详细信息，也不需要花费维护索引或增加阻塞/死锁机会的成本。 @JonathanFite在评论中提到索引和统计数据之间的区别： 索引将通过创建与表本身排序不同的查找来帮助SQL更快地找到数据。统计信息可帮助SQL确定满足查询所需的内存/工作量。 那是个很棒的信息，主要是因为它可以帮助我阐明我的问题： 如何知道这（或在任何其他技术信息什么 S和如何 S的相关的行为和性质STATISTICS）帮助确定何时选择CREATE STATISTICS在CREATE INDEX创建索引将创建相关的时候，尤其是STATISTICS对象？仅具有统计信息而不具有索引会更好地服务于哪种情况？ 如有可能，提供一个工作场景示例，说明该STATISTICS对象比物体更合适，这对超级骗子很有帮助INDEX。 因为我是一个视觉学习者/思想家，所以我认为并排查看es STATISTICS和INDEXes 之间的差异可能会有所帮助，这是帮助确定何时STATISTICS是更好选择的一种可能方法。 Thingy PROs CONs ------- ---------- ------------------- INDEX * Can help sorts. * Takes up space. * Contains data (can * Needs to be maintained (extra I/O). "cover" a query). * More chances for blocking / dead-locks. …
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 | …
3
MySQL状态变量Handler_read_rnd_next增长很多
在MYSQL状态下，Handler_read_rnd_next值非常高。 我知道，当执行没有适当索引的查询时，此值将增加。 但是，即使执行“ Handler_read_rnd_next”之类的显示状态，该值也会增加2。 基于此状态标志，我们正在监视一些统计信息。 因此，每次这些统计数据都显示为关键。 我们可以从“ Handler_read_rnd_next”计数中排除这些“显示”执行计数吗？ 另一个例子 有一个包含10行的表，该表在“数据”列上建立索引，并且如果我们执行以下查询： select data from test where data = 'vwx' -> returns one row 如果我们检查'Handler_read_rnd_next'的值，它会增加7。 以下是上述查询的explain命令的结果： explain select data from test where data = 'vwx'; id, select_type, table, type, possible_keys, key, key_len, ref, rows, Extra 1, 'SIMPLE', 'test', 'ref', 'data', 'data', '35', …
1
UPDATE STATISTICS…WITH ROWCOUNT后如何重置统计信息
为了进行查询调整和测试，您可以通过运行手动将行计数和页计数分配给表的索引统计信息UPDATE STATISTICS。但是，如何将统计信息重新计算/重置为表的实际内容？ --- Create a table.. CREATE TABLE dbo.StatTest ( i int NOT NULL, CONSTRAINT PK_StatTest PRIMARY KEY CLUSTERED (i) ); GO --- .. and give it a thousand-or-so rows: DECLARE @i int=1; INSERT INTO dbo.StatTest (i) VALUES (@i); WHILE (@i<1000) BEGIN; INSERT INTO dbo.StatTest (i) SELECT @i+i FROM dbo.StatTest; …
3
为什么将自动更新统计信息设置为False？
作为更广泛的收购项目的一部分，我刚刚继承了大约20个SQL Server实例。我正在评估性能，我不喜欢实施维护计划的方式。 我看到每天进行一揽子索引重建（我可以处理这一问题），并且每天都在手动更新统计信息。 大约一半的数据库已设置为“自动更新统计信息= False”，原因除了我被告知要减少“性能问题”外，其他原因还不清楚。 我一直认为并努力将其设置为True的最佳实践，并认为如果此设置为True，则不需要手动更新。我错了吗？ 谁能解释一下将此设置为False会有什么好处，但是每天进行一次手动更新呢？ 我应该提到，某些数据库具有很高的事务性（每天有数以百万计的插入，删除，更新），而其他数据库的事务处理率很低，而有些则全部是只读的。尽管没有任何韵律或原因，但关于“自动更新”设置为“否”的信息。好像是彩票。
1
查询性能不佳
我们有一个很大的过程（10,000行以上），通常需要0.5-6.0秒才能运行，具体取决于要处理的数据量。在过去一个月左右的时间里，在我们使用FULLSCAN更新统计信息后，开始花费了30秒钟以上。当速度变慢时，sp_recompile会“修复”该问题，直到夜间统计作业再次运行。 通过比较慢速执行计划和快速执行计划，我将其范围缩小到了特定的表/索引。当它运行缓慢时，它估计将从特定索引返回大约300行，而当它运行速度较快时，它估计将有1行。当它运行缓慢时，在对索引执行查找后将使用表后台处理程序；而当它运行速度较快时，它将不执行表后台处理程序。 使用DBSS SHOW_STATISTICS，我在excel中绘制了索引直方图。我通常希望该图更像是“起伏的丘陵”，但相反，它看起来像一座山，最高点比该图上的其他大多数值高2x-3x。 如果我在没有FULLSCAN的情况下更新统计信息，它看起来会更正常。如果我再次使用FULLSCAN运行它，则看起来就像我上面描述的那样。 这感觉像一个参数嗅探问题，并且特别与上面的（看似）怪异的索引分布有关。 proc接受表值参数，表值参数上是否可以进行参数嗅探？ 编辑：proc还需要12个其他参数，其中一些是可选的，其中两个是开始日期和结束日期。 直方图是奇数，还是我吠错了树？ 我当然很愿意尝试调整查询和/或尝试调整索引。如果那是很好的解决方案，那时候我的问题更多是关于偏斜的直方图。 我应该提到这是PK IDENTITY聚集索引。我们有两个互相通信的系统，一个是旧系统，一个是新的本地系统。两个系统都存储相似的数据。为了使它们保持同步，即使将数据添加到旧系统中（完成RESEED处理），也可以在将新事物添加到旧系统中后在新系统中的此表上增加PK。因此，此列中的编号可能存在​​一些差距。记录很少删除（如果有的话）。 任何想法将不胜感激。我非常高兴收集/包含更多信息。
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.