标签: statistics

我正在管理一个运行使用 PostgreSQL 的工具的服务器。该工具自行处理大多数 PostgreSQL 配置，但我观察到一些性能问题。我可以在操作系统级别确认正在发生大量 I/O，因此我怀疑正在发生大量缓存未命中。

如果您在互联网上寻找“缓存未命中”或“缓存未命中 postgresql”或类似的搜索，您会发现很多对“ cache_miss 统计信息”的引用。但是没有任何地方解释如何获得它们！我有点理解，该值必须从 fetches 中减去命中来计算。但由于我不是经验丰富的数据库管理员，我真的不明白价值观的意思:-S

我找到了PostgreSQL - Monitoring Database Activity文档，但我不确定以下公式是否是我所需要的：

cache_miss = "result_of" pg_stat_get_db_blocks_fetched(oid) - "result_of" pg_stat_get_db_blocks_hit(oid)

对假人的解释将不胜感激。

先感谢您！

我们的生产 SQL Server 2008 R2 有时开始执行缓慢：所有查询开始工作太慢（有时所有查询只是挂起并等待某些事情然后继续）。这通常持续几分钟。

我读过有时自动更新统计信息会降低服务器的速度：

是否有理由手动更新统计信息？

我看到有时会为相当大的索引（1.7 GB 大小，550 万行的表）发生自动更新统计信息。我可以通过 STATS_DATE 看到最近更新统计数据的日期，但是我看不到这个过程的持续时间。

请您建议我如何查看统计数据自动更新的持续时间？或者如何确定自动更新统计信息会导致问题？

谢谢你。

PS 在我们遇到这些性能问题后，我开始监视等待统计信息。最高等待类型是 CXPACKET。它占所有等待的 36% 到 60%。而在早上，当工作日开始时，它在工作日内达到最大值（用户通常每天使用应用程序工作 12 小时）。第二高的等待类型是 SOS_SCHEDULER_YIELD (15%-20%)。
我在互联网上发现了一些帖子，其中提到 CXPACKET 等待时间显示自动更新统计数据会产生问题。但我还没有找到这种说法的真正证据。我很清楚 CXPACKET 可以显示并行执行 SQL 查询的问题（来自http://www.dbadiaries.com/reducing-sql-server-cxpacket-wait-type）。

我有一个相当大的表（约 2 亿行），虽然统计数据是最新的WITH FULLSCAN，但我的直方图（限制为 200 步）是否可能过于宽泛，优化器无法做出正确的估计 - 换句话说，是不是已经不够“选择性”了？使用这个特定客户的数据库/表，我的查询计划估计与其他人相比相差甚远。

我关注的特定统计数据来自表的 PK/CLUSTERED INDEX。它是一个包含int( ParentId) 和smalldatetime( TimeStamp)的多列统计信息。

当我发出 a 时DBCC SHOW_STATISTICS('SomeTable', 'PK_SomeTable')，我得到以下输出（省略了直方图 - 但如果有帮助，我可以发布它）：

Name                    Updated              Rows       Rows Sampled    Steps   Density         Average key length  String Index    Filter Expression   Unfiltered Rows
PK_SomeTable            Jan 31 2014 10:59AM  181170887  181170887       200     2.022617E-05    8                   NO              NULL                181170887

All density     Average Length  Columns
0.0004892368    4               ParentId
5.519651E-09    8               ParentId, TimeStamp

我的大部分查询都是使用这两个列 (ParentId和TimeStamp)的组合来执行的。小的 all 密度值显示了这对的选择性 …

使用sp_updatestats不重新采样更新表的统计信息和使用UPDATE STATISTICS不带重新采样更新表的统计信息之间有什么区别吗？sample options(FULLSCAN,SAMPLE PERCENT,RESAMPLE)

exec sp_updatestats vs 更新统计表名

使用sp_updatestats默认值更新表NO将使用默认采样率更新统计信息。

同样，使用UPDATE STATISTICSwithoutsample options(FULLSCAN,SAMPLE PERCENT,RESAMPLE)更新表的统计信息也会使用默认采样更新表统计信息。

那么这两种方法有什么区别吗？我在这里错过了什么吗？

更新 ：

我知道sp_updatestats在所有表上运行，但使用UPDATE STATISTICS我们可以更新特定表的统计信息。

我注意到涉及 jsonb 列的查询的性能在测试时在 VACUUM ANALYZE 运行之间存在显着差异。分析表格后，我似乎随机得到了完全不同的执行计划。

我在这里使用 Postgres 9.6。我的测试设置如下，我将一个键“x”插入到 jsonb 列“params”中，值在 1 到 6 之间，1 是最稀有的值，6 是最常见的值。我还有一个常规的 int 列“single_param”，其中包含用于比较的相同值分布。：

CREATE TABLE test_data (
    id      serial,
    single_param    int,
    params      jsonb
);

INSERT INTO test_data
SELECT 
    generate_series(1, 1000000) AS id, 
    floor(log(random() * 9999999 + 1)) AS single_param,
    json_build_object(
        'x', floor(log(random() * 9999999 + 1))
    ) AS params;

CREATE INDEX idx_test_btree ON test_data (cast(test_data.params->>'x' AS int));
CREATE INDEX idx_test_gin ON test_data USING GIN (params);
CREATE INDEX ON test_data(id)
CREATE INDEX ON test_data(single_param)

我正在测试的查询是对结果进行分页的典型查询，我按 …

我的数据库中有一些自动生成的 _WA_Sys_ 统计信息，它们有一段时间没有更新（与同一个表中的其他统计信息相比）

经验法则似乎是在大于 500 行的表中，统计信息在 20% + 500 行数据更改时更新。

但是，我可以看到使用以下查询

SELECT  t.name,
        i.name,
        i.rowcnt,
        i.rowmodctr,
        p.last_updated
FROM    sys.sysindexes i
        JOIN sys.tables t
            ON i.id = t.object_id
        JOIN sys.stats s
            ON s.object_id = t.object_id AND i.name = s.name
        CROSS APPLY sys.dm_db_stats_properties(s.object_id,s.stats_id) p
WHERE   rowmodctr > 0
ORDER BY i.rowmodctr DESC

有一个表包含许多过时的 _WA_Sys_ 统计信息（并且 rowmodctr 高于 20% + 500）

如果对表运行查询并在 WHERE 子句中添加与过时 _WA_Sys_ 统计信息关联的列之一并检查统计信息的更新日期，我可以看到它已更新。

如果我再次使用 WHERE 子句运行相同的查询，则统计信息不会更新

似乎 _WA_Sys 统计信息在运行查询时更新，将使用它们并且它们已过时？

我不确定我从哪里开始，但是有没有办法查看优化器为查询生成查询计划花费了多长时间？它是否存储在任何 DMV 或某个统计数据的一部分中？或者，如果我包含实时统计数据或实际执行计划，我可以以某种方式计算它吗？也许在查询存储中？

我们正在对具有大量数据的 SQL Server 数据库运行密集的应用程序负载（数千次操作/秒）。有些表有数十亿行，其中一些有大量插入和更新。

DB 性能一般都还可以，但我们会时不时地遇到查询性能问题；以前运行良好的相当简单的查询可能会突然花费 10-100 倍的时间。

这似乎与表/索引统计信息和查询优化器有关 - 大多数情况下，统计信息更新将解决问题，然后再次更新统计信息会使情况变得更糟（然后重新运行统计信息更新通常会解决问题最终）。

似乎正在发生的事情是优化器决定对某些查询使用客观错误的索引；突然之间，在使用了正确的方法数天和数周之后。

我的问题是：为什么会发生这种情况，我们能做些什么？

这个数据库已经运行了多年，负载基本相同，查询几乎相同，更新量也相同。对于 99.995% 的查询，应该没有理由随着时间的推移决定不同的索引策略，无论输入如何（而且 - 实际上 - 这样做会明显地完全破坏查询性能）。

如上所述，按计划自动更新统计数据通常会产生可怕的问题——如果统计样本出现偏差（这似乎至少有 5% 的情况发生），我们最终会陷入痛苦的世界。

有没有办法告诉SQL Server（在某些表上）统计直方图和密度不会随时间变化，所以请继续对涉及该表的查询使用相同的查询计划？如果不是，我们如何确保随着时间的推移统计更新的可预测结果（避免上述的偏斜统计问题）？

没有存储过程。我们确实可以控制 SQL，因此它可能会被更改，但它有很多代码，因此如果我们必须更改每个查询（例如添加附加子句），那将是不幸的。

一个后续问题：参数嗅探似乎只与存储过程相关，对吗？

我已经将几个大型表（每个都有 >10^9 行和几十列）从 SQL Server 2014 实例上的聚集行存储移动到聚集列存储索引，并注意到这些表上的统计信息更新（默认采样，在我们的 ETL 中触发）或来自 Hallengren 脚本）现在需要更长的时间。

一个更具理论性的问题是为什么会这样？我的疯狂猜测是，统计信息更新会产生大量随机读取，这与列存储索引不能很好地配合，因为它们更适合大量数据的顺序读取。我很高兴知道更“深入”的解释。

更重要的问题是我是否可以做点什么来反对它。我已经在 SQL Server 2017 实例上尝试了针对具有单个 bigint 列（见下文）的表的测试用例，得到了相同的结果。增量统计在纸面上似乎是一个很好的解决方案。我需要重新创建所有统计对象（目前不是增量的，可能是由于历史原因），扩展 ETL 逻辑并更新我们的 Hallengren 脚本版本（我们目前使用旧版本）。如果有人能在我进入这个兔子洞之前分享他/她的经验，我将不胜感激。

重现步骤：

/*Create a rowstore and a columnstore table with a single bigint column*/
CREATE TABLE dbo.rowstore (col1 BIGINT);
GO

CREATE TABLE dbo.columnstore (col1 BIGINT);
GO

CREATE CLUSTERED COLUMNSTORE INDEX CCI_columnstore ON dbo.columnstore;
GO

/*Fill both tables with 400 * 10^6 rows. This results in a 15GB large rowstore and a 3,1GB large columnstore tables*/
;WITH e1(n) AS …

我有一个关于表中主键列的统计信息。当我使用默认选项更新统计信息时：

UPDATE STATISTICS dbo.MyTable PK__MyTable__CB394B3946083350

我得到一个直方图如下（删节）

                    RANGE_HI_KEY                      RANGE_ROWS                         EQ_ROWS             DISTINCT_RANGE_ROWS                  AVG_RANGE_ROWS
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
                      3400002201                               0                               1                               0                               1
                      3400009992                        18103.04                               1                            7790                        2.323882
                      3400040033                        26083.68                               1                           26080                        1.000144
                      3400050456                        13029.09                               1                           10422                        1.250153
                      3400087676                        26083.68                               1                           26080                        1.000144
                      3400103858                        19556.38                               1                           16181                        1.208602
                      3400126866                        13029.09                               1                           13029                               1
                      3400162832                        39138.27                               1                           35965                        1.088232
                      3400213115                        45665.56                               1                           45641                        1.000547
                      3400238444                        26083.68                               1                           25328                        1.029836
                      3400242626                        13029.09                               1                            4181                        3.116262
                      3400262174                        19556.38                               1                           19547                         1.00048
                      3400283983                        26083.68                               1                           21808                         1.19606
                      3400304837                        19556.38                               1 …