标签: statistics

特定于 Microsoft SQL Server...

如果查询具有针对段落样式文本列的搜索谓词，它将创建系统创建的统计信息来回答查询。

知道了。

我的问题是是否应该稍后删除这些，因为它们没有多大帮助，因为它们纯粹基于文本字符串的前几个字符，并且在搜索中实际上没有用，这将是对表格的扫描，无论如何什么。稍后通过自动统计更新的“梳理”操作或自行开发的统计梳理过程会遇到这些并可能尝试更新它们。
更复杂的是，该列通常是“宽”的，并且通常可以是“深”的（例如，一亿多行）并导致大量 IO 命中以完成即使是小样本扫描以更新统计数据。

我的想法使我说它们应该被删除。别人怎么说？

我不是在问对这些类型的数据的查询是否可取。他们发生了。我只是怀疑这些自动生成的统计数据的用处及其存在的理由，除非您碰巧有一个文本列，其中前几个字符实际上对查找您需要的行有用 - 足以让您考虑创建一个索引那个专栏 - 我希望这是不寻常的。

你说什么？保留这些信天翁还是摆脱它们？

我正在对同步与异步自动统计更新进行一些测试。我想快速使所有统计对象（标题、密度向量和直方图）失效，以确保下次使用统计时会更新。

我正在尝试模拟统计数据的自动更新，而不是自动创建。

理想情况下，我不想更改行数，因此我已取消INSERT/DELETE操作。理想情况下，我也不想更改任何数据值，我已经考虑使用UPDATE语句，但我认为这在我的一些较大的表上可能需要太长时间。

我已经看过了，UPDATE STATISTICS WITH ROWCOUNT, PAGECOUNT但我认为这不是我所追求的。我希望可能有一个跟踪标志或未记录的命令会使统计数据无效。

有没有一种快速有效的方法来完成我没有考虑过的我想要实现的目标？

我正在 SQL Server 2016 上进行测试。

我的应用程序通常需要准确但可能不完美的行数。十亿行的表经常会被频繁写入，所以“完美”是定义和时间的问题。

Microsoft SQL 保留了非常好的元数据，允许进行如下查询：

SELECT SUM(rows) FROM sys.partitions
WHERE object_id = object_id('TABLE_NAME') 
AND index_id < 2;

（还有其他具有不同元数据的方法）。这提供了近乎完美的行数，可能会忽略某些正在进行的事务或其他细节。这些技术适用于除最苛刻的情况之外的所有情况，并且几乎是即时的。

在 Oracle 中，我们可以使用统计信息：

SELECT num_rows
FROM all_tables
WHERE table_name = 'TABLE_NAME'

这是不可靠的，因为如果完全收集了统计信息，根据 DBA 策略，它们通常已经过时。

我可以牺牲显着的准确性来使用采样来提高速度：

SELECT COUNT(*) * 1000 rc_sampled FROM lot_size SAMPLE(.1) SEED(42)

然而，这是不准确的设计，还是相当慢（115秒在500M行测试），并且几乎是无用的，当应用程序不已经有一个行数的估计。在一个有 800 行的表上运行该 SQL 就像问，“那个糖果棒的价格是多少，给予或接受 75.00 美元？”）

Oracle 是否提供了一种实用的方法来获得任意表的准确、快速的行数，例如 Microsoft SQL 和其他提供的表？

我正在处理一个查询，将所有直接或间接依赖于任何级别的数据库对象提供给一个名为 的表dbo.tblborder，该表严重依赖。

但是，这个问题特别与此查询的查询计划有关，因为我在查询计划中看到警告（在不同的排序运算符中）两种类型的警告，一种与溢出到 tempDB 相关，另一种与转换相关的警告数据类型和基数估计。

查询和查询计划进一步向下，在图片之后。

问题

在处理系统对象时，如何找出需要更新统计信息的对象？

否则，如何摆脱查询计划上的这个警告？

关于数据类型转换，我可以做些什么来避免这种情况以及基数估计问题？

也许是一些跟踪标志？

它是一个 600GB 的数据库，我想找到特定表上的所有依赖项，仅第一级就显示了 325 个对象，但这不是我每天都会运行的查询。我对清除这些警告很感兴趣，但这不是生死攸关的问题。

信息

第 1 张关于 tempdb 溢出警告的图片：

关于 tempdb 溢出警告的第二张图片：

第三个警告 - 与数据类型转换相关，可能会影响基数估计：

;WITH Radhe AS (

            SELECT DISTINCT 
            s2.object_id, 
            Name=SCHEMA_NAME(S2.schema_id) + '.' + S2.Name, 
            ObjectType = S2.Type,
            DependsOn = s1.object_id,
            DependsOn_Name=SCHEMA_NAME(S1.schema_id) + '.' + S1.Name,  
            0 as Level

            FROM sys.sysdepends DP

            INNER JOIN sys.objects S1 
                    ON S1.object_id = DP.DepID

            INNER JOIN sys.objects S2 
                    ON S2.object_id = DP.ID

            WHERE S1.object_id = …

多年来，我们一直在使用 Ola Hallengren 的维护脚本对 OLTP 数据库进行索引优化。（我们在 sql server 2008 R2 上）2 周前，尽管这里的一位 DBA 创建了一个维护作业来单独更新统计信息，并且在索引优化作业之前每周运行一次。似乎在创建它之后，我们在少数存储过程中遇到了性能问题。我对统计维护不太熟悉，所以我想知道，是否真的有必要单独运行每周工作来更新所有统计数据？
这里的 DBA 似乎认为这是必要的，但我觉得在维护作业运行后的第二天早上，我们开始执行糟糕的存储过程，我经常需要每天至少重新编译相同的存储过程 1 或 2 次，以用于以下几个几天然后问题就停止了。我的理论指向之前发生的统计更新，但我找不到原因。无论如何，在进行一定量的更改或索引重建期间，统计信息是否会更新？为什么单独重新计算它们会导致问题？

有没有人能够澄清为什么每次更新统计信息时相同的存储过程都会发生这种情况？

这是用于统计作业的命令：

EXECUTE dbo.IndexOptimize 
    @Databases = 'DB_PRO', 
    @FragmentationLow = NULL, 
    @FragmentationMedium = NULL, 
    @FragmentationHigh = NULL, 
    @UpdateStatistics = 'ALL', 
    @OnlyModifiedStatistics = 'Y' , 
    @TimeLimit = 3600, 
    @LogToTable = N'Y'; 

然后索引维护作业运行如下：

    sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d master -Q "EXECUTE [dbo].[IndexOptimize] 
    @Databases = 'DB_PRO', @TimeLimit = 10800, @LogToTable = 'Y'" -b

我正在尝试优化一个与此类似的查询：

select top(1)
    t1.Table1ID,
    t1.Column1,
    t1....
    ....
    t2.Table2ID,
    t2....
    ....
    c.FirstName,
    c.LastName,
    c....
from BigTable1 t1
join BigTable2 t2
    on t1.Table1ID = t2.Table1ID
join Customer c
    on t2.CustomerID = c.CustomerID
join Table4 t4
    on t4.Table4ID = t2.Table4ID
join Table5 t5
    on t5.Table5ID = t1.Table5ID
join Table6 t6
    on t6.Table6ID = t5.Table6ID
where 
    t4.Column1 = @p1
    and t1.Column1 = @p2
    and t3.FirstName = @FirstName
    and t3.LastName = @LastName
    and t6.Column1 = @p5
    and (@p6 is null or t2.Column6 = @p6)
order …

关于SET STATISTICS TIME ON并且SET STATISTICS IO ON我在 Microsoft 文档的评论中注意到，它说如下：

STATISTICS IO 为 ON 时，显示统计信息，OFF 时，不显示信息。

将此选项设置为 ON 后，所有 Transact-SQL 语句都会返回统计信息，直到该选项设置为 OFF。

这是否意味着在当前连接或整个服务器中执行的所有 Transact-SQL 语句？当我自己测试时，它似乎只在我的连接范围内。

根据 MS 文档，其描述AVG_RANGE_ROWS是：

直方图步骤中具有重复列值的平均行数，不包括上限。当 DISTINCT_RANGE_ROWS 大于 0 时，通过将 RANGE_ROWS 除以 DISTINCT_RANGE_ROWS 来计算 AVG_RANGE_ROWS。当 DISTINCT_RANGE_ROWS 为 0 时，AVG_RANGE_ROWS 为直方图步骤返回 1。

我期待在最后一行，如果的确是这样，我很好奇，想知道为什么我看到一个值AVG_RANGE_ROWS是不相等1的时候DISTINCT_RANGE_ROWS是0在直方图步骤。

有问题的统计信息是 SQL Server 在启用自动创建统计信息选项时创建的列统计信息。我使用的是旧版本的数据库，但使用的是最新补丁 - SQL Server 2014 SP3、CU4+GDR (12.0.6372.1)。

有点不幸的是，由于次优查询计划，我们上周几乎崩溃了。最终结果是大扫描和膨胀的内存授权。使用更高的百分比值重新采样统计数据暂时为我们解决了这个问题，但我很想知道初始语句或已知问题是否存在异常（可能使用跟踪标志解决？）以及如何解决对于我们无法控制采样大小的自动创建的统计数据，我如何防止这种情况再次发生？

我正在做一个必须支持两个数据库引擎的项目；SQL Server 和 PostgreSQL。

我们使用 NHibernate 作为 ORM。

我们遇到了某些查询的性能问题。使用 SQL Server 工具，我们提出了几个新的索引和统计数据，大大提高了 SQL Server 的性能。但是，我不确定如何在 PostgreSQL 上实现相同的索引和统计信息。

两个例子是：

    CREATE STATISTICS [perfStat_Answer_02] ON [dbo].[Answer] 
    ([InclusionExpressionGroupId], [QuestionId], [AnswerId])

    CREATE NONCLUSTERED INDEX [perf_Answer_01] ON [dbo].[Answer] 
    (
        [QuestionId] ASC
    )
    INCLUDE ( 
            [AnswerId],
            [InclusionExpressionGroupId],
            [AnswerConceptId],
            [Revision],
            [AnswerText],
            [AnswerOrder]
    )
    WITH (
            SORT_IN_TEMPDB = OFF
            , IGNORE_DUP_KEY = OFF 
            , DROP_EXISTING = OFF
            , ONLINE = OFF)
    ON [PRIMARY]

INCLUDE如果存在这样的功能，PostgreSQL 中 d 字段的语法是什么？

我们如何添加统计信息？

阅读 PostgreSQL 文档，我不相信两者都受支持。但是，我想知道是否有任何方法可以完成类似的事情。

我正在优化一些使用数据库的服务器应用程序任务（查询、复杂计算、数据插入......）。执行此任务大约需要 16 分钟（我已经测试了 3 次以上），并且执行时间是可预测的。
然后我执行了脚本：

ALTER INDEX ALL ON dbo.'+ @TableName +' REBUILD

对于数据库中的每个表。还有我现在看到的。我的任务的执行时间增加到 24 分钟。如果这些对这项任务没有任何外部影响，会发生什么？我正在等待性能提高（由于重建碎片索引）但性能下降。