标签: statistics

我正在尝试改进此子查询（较大查询的）的行估计。估计显示 1266 行。实际是 117k 行。这个特定的属性（EAV 模式）只定义了两个值（2 和 3）：

declare @pPropVal smallint = 2;

select Value, ObjectId 
  from Oav.ValueArray PropName
 where PropName.PropertyId = 897
   and PropName.Value  = @pPropVal
option (recompile)

查询计划按预期显示对 PropertyId 和 Value 索引 IX_ValueArray_PropValObj 的正确搜索谓词。

( A ) 作为改进行估计的尝试，添加了一个额外的统计数据，使行估计略微增加到 3041：

create statistics [ST_SomePropertyName] ON [Oav].[ValueArray](PropertyId, Value, ObjectId)
 where 
     (     
             PropertyId = 897 
         and [Value] is not null
     )
  with fullscan

直方图显示单行。HI 键只是 PropertyId（第一列），根据我的理解，它不是那么有用，它使用的是密度信息。

RANGE_HI_KEY    RANGE_ROWS  EQ_ROWS  DISTINCT_RANGE_ROWS  AVG_RANGE_ROWS
897             0           196026   0                    1

All density Average Length  Columns
1 …

在系统中有一个夜间数据加载过程，其中删除所有外键，截断所有表，从外部源重新填充，并将外键放回原位。

在此过程结束时，我希望 sp_updatestats运行，以便更新所有这些新数据的统计信息。

但是，在检查代码时，我注意到以下行：

EXEC sp_MSforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN'

你能把它比作跑步sp_updatestats吗？那就是一个与另一个的区别和优点/缺点是什么？

我们最近将许多实例升级到 2016 年。因此，来自sqlpackage.exe的 SELECT 语句在某些实例上超时。

经过一些测试，我发现通过更新执行计划中显示的数据库系统表的统计信息，SELECT 停止了超时。

update statistics sys.[sysclsobjs] with fullscan
update statistics sys.[syscolpars] with fullscan
update statistics sys.[sysidxstats] with fullscan
update statistics sys.[sysiscols] with fullscan
update statistics sys.[sysobjvalues] with fullscan

无论如何，是否可以通过标准维护包、Ola Hallengren 的脚本或其他一些过程来仅更新系统表统计信息？

08/01 更新

以下是我升级后的步骤

关于 4199 跟踪标志KB974006

-- for the instance
/* 
Turn on traceflag 4199 (my understanding of this traceflag is that it disables
optimizer hotfixes in 2016
*/

-- disable automatic numa
sp_configure 'automatic soft-NUMA disabled', 1
GO

-- For each …

在 Postgres 中，ANALYZE收集有关数据库中表内容的统计信息，并将其存储。这些统计信息用于确定 PG 中最有效的查询计划。运行analyze命令提高了数据库的性能。我想知道 SQL Server 中是否有类似的东西。

SQL Server 是否具有与 Postgres'Analyze和等效的命令Vacuum？

如果 SQL Server 没有完全等效的命令，是否有类似的命令？

如果这些命令确实有 SQL Server 版本，请解释它们或张贴有用文档的链接。

我有一个PostgreSQL包含数百个函数的旧数据库模式。我知道其中一些不再使用了，我想删除它们。

查找有时执行哪些过程而哪些不执行的最简单方法是什么？PostgreSQL 中是否有任何关于过程使用的统计数据？

使用的引擎版本为 PostgreSQL 9.5。

我有一个表dbo.ClaimBilling，有 130,000 行。在该表中，列OperatorID是 avarchar(max)并且严重倾斜。125,000 行是 'user1'，其余 5000 行分为 6 个其他值，'user2' 共有 3 条记录。

上有一个非聚集索引OperatorID，聚集索引是主键，IDClaimBilling。

我目前有以下查询：

SELECT DISTINCT IDClaimBilling
FROM dbo.ClaimBilling cb
INNER JOIN dbo.BillingItem bi
    ON cb.IDClaimBilling = bi.ClaimID
WHERE OperatorID = @operator

不管是什么值@operator，来自行的估计ClaimBilling都是~4000，这与任何值会返回的值都不接近，而且它始终是聚集索引扫描，它不使用operatorID索引。如果我删除加入并做

SELECT DISTINCT IDClaimBilling
FROM dbo.ClaimBilling
WHERE OperatorID = @operator

然后它确实使用了OperatorID索引，但是无论 的值如何，估计都是错误的@operator，这次总是估计 ~18,000 左右。

我UPDATE STATISTICS dbo.ClaimBilling WITH FULLSCAN在运行查询之前做了一个。

即使统计信息确切地知道每个值有多少行，为什么这些估计值如此错误？

我@operator在测试中声明并分配一个值。它最初是程序的一部分，我认为这就是问题所在，但在临时声明中使用时它的行为也是一样的。

该查询仅在用户首次登录时运行，因此每个用户每天可能只运行几次。

快速而简单...为什么当我尝试检索临时表中某一列的统计信息时此 sp 失败？

CREATE PROCEDURE dbo.Demo
AS
BEGIN
SET NOCOUNT ON
-- Declare table variable
CREATE TABLE #temp_table (ID INT)
DECLARE @I INT = 0

-- Insert 10K rows
    WHILE @I < 100
    BEGIN
        INSERT INTO #temp_table VALUES (@I)

        SET @I=@I+1
    END

-- Display all rows and output execution plan (now the EstimateRow is just fine!)
SELECT * FROM #temp_table

-- Is the object there
SELECT OBJECT_ID('tempdb..#temp_table')

-- How about statistics
DBCC SHOW_STATISTICS ('tempdb..#temp_table', 'id')
END;

我不明白，我收到一条消息说没有在列 id 上创建统计信息

Could …

我使用 PostgreSQL 9.6。

我有一个连接 17 个表的查询，其中 9 个有几百万行。查询运行良好，但本周其性能迅速下降。EXPLAIN 的输出没有帮助（所有扫描都是索引扫描，除了非常小的表），我不得不尝试从查询中删除表以隔离导致降级的表。

事实证明，一个包含 40 行的不起眼的表破坏了查询：800 ms 没有该表，而有 30 s。我在桌子上运行了 VACUUM FULL，它运行了大约一秒钟，现在性能恢复正常。

我的问题：

1. 什么可以解释 <10kb 的表像这样破坏性能？
2. 以后如何避免同样的问题？

在调试过程中，我对另一台服务器进行了基本备份，因此我有两个文件系统级别的数据库副本，其中一个我没有运行 VACUUM FULL。当我使用 pgAdmin 登录到 unvacuumed 副本时，我收到以下消息：

表“public.clients”上的估计行数与实际行数显着不同。您应该在此表上运行 VACUUM ANALYZE。

unvacuumed 表有 40 行计数和 0 估计。以下是屏幕截图中的其余统计数据。

我有一个包含 2200 万条记录的表。

我注意到一列的统计数据很差，即使该列具有恒定分布：实际上，每个值都重复两次。

为了帮助您可视化此场景，请考虑一个表，其中包含另一个表的每个唯一 ID 的签入和签出日期（2 个不同的记录）。

这些是完整扫描的统计信息：

这些是自动采样的统计数据：

为什么会有这种奇怪的行为？是否有一些经验法则可以确定正确的采样率，或者是否需要全扫描？我应该为某些统计信息创建一个带有 fullscan 的统计更新作业吗？如果是这样，我怎么知道哪些统计数据需要这种处理？

附加信息：

• 该列没有外键约束
• 该列是一个 numeric(14,0) NULL

我有一个包含十亿级表的 Postgres 数据库。所以任何聚合函数，例如count() 和avg()，以及“order by random()”都是非常耗时的。Postgres 有 pg_catalog，其中包含许多描述数据库的有用统计信息（例如视图 pg_stats 中的直方图箱）。有没有办法利用 pg_catalog 中的统计信息来估计 Postgres 表中数字列的平均值和中位数？