Questions tagged «cardinality-estimates»

我正在使用SQL Server 2012 Enterprise。我遇到了一个SQL计划，该计划表现出一些我不完全直观的行为。在执行大量并行索引扫描操作之后，发生了并行（分区流）操作，但是该操作杀死了索引扫描（Object10.Index2）返回的行估计，从而将估计值减小为1。我已经做了一些搜索，但是还没有遇到任何可以解释这种现象的信息。查询非常简单，尽管每个表都包含数百万的记录。这是DWH加载过程的一部分，整个中间数据集都被触及过几次，但是我遇到的问题尤其与行估计有关。有人可以解释为什么并行（Repartition Strems）运算符中的精确行估计为1吗？也， 我已经发布了完整的计划以粘贴计划。 这是有问题的操作： 在添加更多上下文的情况下包括计划树： 我能否碰到Paul White提交的Connect项目的一些变体（在此处，他的博客有进一步的深入探讨）？至少这是我发现的唯一一件事，即使没有TOP运算符，它似乎也几乎接近我所遇到的问题。

12 sql-server  sql-server-2012  execution-plan  cardinality-estimates 

我有特定的清理代码，试图删除一些重复项。 它可以在许多客户站点上完美运行。日志告诉我，此查询至少消耗1秒到45秒： DELETE FROM [tbl] WHERE [Id] NOT IN ( SELECT MIN([Id]) FROM [tbl] GROUP BY [IdProject], [IdRepresentative], [TimeStart] ) 但是我有一个客户，该查询运行了4个多小时（到现在为止还没有结束）！我检查了数据库（DBCC CHECKDB），我已经更新了统计信息（sp_updatestats），也UPDATE STATISTICS [tbl] WITH FULLSCAN没有显示任何更改。 我有客户的数据库原始备份。我在SQL Server 14.0.2002.14上运行它。我有标准版，客户使用Express Edition。 我可以在活动监视器中看到没有其他人正在使用该数据库。无需等待，CPU使用率达到25％（恰好是我4个CPU中的1个）。同样在这个测试用例中，没有其他人正在使用数据库。 我重新设计了查询并检查了以下语句： DELETE FROM [tbl] FROM [tbl] AS t LEFT OUTER JOIN ( SELECT MIN([Id]) AS [IdMin] FROM [tbl] GROUP …

11 sql-server  query-performance  execution-plan  sql-server-2017  cardinality-estimates 

我正在尝试使用实际执行计划上的“显示计划分析”（SSMS）来执行性能缓慢的查询。分析工具指出，行数的估计值与计划中某些位置的返回结果不符，并进一步给了我一些隐式转换警告。 我不理解这些从int到Varchar的隐式转换-引用的字段不是查询中任何参数/过滤器的一部分，并且在涉及的所有表中，列数据类型都是相同的： 我收到以下CardinalityEstimate警告： 表达式中的类型转换（CONVERT_IMPLICIT（varchar（12），[ccd]。[profileid]，0））可能会影响查询计划选择中的“ CardinalityEstimate”-该字段在我的数据库中到处都是整数 表达式中的类型转换（CONVERT_IMPLICIT（varchar（6），[ccd]。[nodeid]，0））可能会影响查询计划选择中的“ CardinalityEstimate”-该字段在我数据库中的每个地方都是smallint 表达式中的类型转换（CONVERT_IMPLICIT（varchar（6），[ccd]。[sessionseqnum]，0））可能会影响查询计划选择中的“ CardinalityEstimate”-该字段在我的数据库中到处都是smallint 表达式中的类型转换（CONVERT_IMPLICIT（varchar（41），[ccd]。[sessionid]，0））可能会影响查询计划选择中的“ CardinalityEstimate”-该字段在我的数据库中到处都是小数 [编辑]这是查询和实际执行计划，以供参考 https://www.brentozar.com/pastetheplan/?id=SysYt0NzN 和表定义 /****** Object: Table [dbo].[agentconnectiondetail] Script Date: 1/10/2019 9:10:04 AM ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[agentconnectiondetail]( [sessionid] [decimal](18, 0) NOT NULL, [sessionseqnum] [smallint] NOT NULL, [nodeid] [smallint] NOT NULL, [profileid] [int] …

11 sql-server  execution-plan  sql-server-2017  type-conversion  cardinality-estimates 

在具有32GB的服务器上，我们正在运行SQL Server 2014 SP2，最大内存为25GB，我们有两个表，在这里您可以找到两个表的简化结构： CREATE TABLE [dbo].[Settings]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceId] [int] NULL, [typeID] [int] NULL, [remark] [varchar](max) NULL, CONSTRAINT [PK_Settings] PRIMARY KEY CLUSTERED ([id] ASC) ) ON [PRIMARY] GO CREATE TABLE [dbo].[Resources]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceUID] [int] NULL, CONSTRAINT [PK_Resources] PRIMARY KEY CLUSTERED ([id] ASC) …

10 sql-server  query-performance  tempdb  cardinality-estimates 

我维护一个存档数据库，该数据库将历史数据存储在分区视图中。分区列是日期时间。该视图下的每个表都存储一个月的数据。 我们使用datetime列上的检查约束来约束每个表上的事件。这使优化器可以限制在搜索表中查找在事件datetime列上进行过滤的查询。 检查约束的名称由SQL Server生成，因此很难通过查看其名称来知道它们的作用。 我希望约束名称的格式为“ CK_TableName_Partition”。 我可以使用此查询并从sql_text列复制数据来生成重命名脚本。WHERE子句匹配检查约束，其名称看起来像是由SQL Server生成的： SELECT checks.name AS check_name, tabs.name AS table_name, skemas.name AS schema_name, cols.name AS column_name, N' EXECUTE sys.sp_rename @objname = N''' + skemas.name + N'.' + checks.name + N''', @newname = N''CK_' + tabs.name + N'_Partition'', @objtype = ''OBJECT'';' AS sql_text FROM sys.check_constraints AS …

10 sql-server  optimization  cardinality-estimates 

将主表连接到明细表时，如何鼓励SQL Server 2014将较大（详细）表的基数估计用作联接输出的基数估计？ 例如，当将10K主行连接到100K详细信息行时，我希望SQL Server估计100K行的联接-与详细信息行的估计数量相同。如何构造查询和/或表和/或索引，以帮助SQL Server的估计器利用每个详细信息行始终都有一个对应的主行这一事实？（这意味着它们之间的连接永远不会降低基数估计。） 这里有更多细节。我们的数据库有一个主/明细表对：VisitTarget每个销售交易VisitSale都有一行，而每个交易中每个产品都有一行。这是一对多的关系：一个VisitTarget行，平均10个VisitSale行。 这些表如下所示：（我将简化为该问题的相关列） -- "master" table CREATE TABLE VisitTarget ( VisitTargetId int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, SaleDate date NOT NULL, StoreId int NOT NULL -- other columns omitted for clarity ); -- covering index for date-scoped queries CREATE NONCLUSTERED INDEX IX_VisitTarget_SaleDate ON VisitTarget …

9 sql-server  sql-server-2014  execution-plan  cardinality-estimates 

我有3个“大”表，它们连接在一对列（均为int）上。 Table1拥有约2亿行 Table2拥有约150万行 Table3拥有约600万行 每个表都有一个聚集索引Key1，Key2以及再得一列。Key1具有低基数并且非常偏斜。WHERE子句中始终引用它。条款中Key2从未提及WHERE。每个联接都是多对多的。 问题在于基数估计。每个连接的输出估计值变小而不是变大。当实际结果达到数百万时，最终得出的结果估计只有几百个。 我有什么办法让行政长官提示做出更好的估计？ SELECT 1 FROM Table1 t1 JOIN Table2 t2 ON t1.Key1 = t2.Key1 AND t1.Key2 = t2.Key2 JOIN Table3 t3 ON t1.Key1 = t3.Key1 AND t1.Key2 = t3.Key2 WHERE t1.Key1 = 1; 我尝试过的解决方案： 在创建多列统计Key1，Key2 创建大量已过滤的统计信息Key1（这很有帮助，但是我最终在数据库中获得了数千个用户创建的统计信息。） 掩盖的执行计划（抱歉掩盖不好） 就我而言，结果有900万行。新的CE估计有180行；旧版CE估计有6100行。 这是一个可重现的示例： DROP TABLE IF EXISTS #Table1, #Table2, …

9 sql-server  join  sql-server-2016  many-to-many  cardinality-estimates 

我正在尝试了解SQL Server如何尝试估计SQL Server 2014中的“大于”和“大于等于” where子句。 我想我确实了解基数估算，例如当我踏上台阶时 select * from charge where charge_dt >= '1999-10-13 10:47:38.550' 基数估计为6672，可以很容易地计算为32（EQ_ROWS）+ 6624（RANGE_ROWS）+ 16（EQ_ROWS）= 6672（以下屏幕截图中的直方图） 但是当我这样做 select * from charge where charge_dt >= '1999-10-13 10:48:38.550' （将时间增加到10:48，所以不是一步） 估计是4844.13。 该如何计算？

9 sql-server  sql-server-2014  performance-tuning  cardinality-estimates