标签: execution-plan

我的查询是：

SELECT  Acol1, Acol2, Bcol1, Bcol2, Ccol1, Ccol2
FROM    tableA LEFT JOIN
            (tableB FULL JOIN tableC ON (Bcol1 = Ccol1))
            ON (Acol1 = Bcol1)

EXPLAIN ANALYZE给我：

                                                      QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
 Hash Right Join  (cost=99.65..180.45 rows=1770 width=24) (actual time=0.043..0.103 rows=3 loops=1)
   Hash Cond: (tableb.bcol1 = tablea.acol1)
   ->  Hash Left Join  (cost=49.83..104.08 rows=1770 width=16) (actual time=0.011..0.062 rows=3 loops=1)
         Hash Cond: (tableb.bcol1 = tablec.ccol1)
         ->  Seq Scan on tableb  (cost=0.00..27.70 rows=1770 width=8) (actual time=0.001..0.002 rows=3 loops=1)
         ->  Hash  (cost=27.70..27.70 rows=1770 width=8) (actual time=0.004..0.004 …

我得到了一个大型执行计划，我正在尝试找到与高成本相关的节点。SSMS 提供了一个搜索实用程序，但是，我没有找到搜索百分比成本值的选项。鉴于下图，我如何搜索导致 21% 成本的节点？第二个输入允许选择equals和contains。是否可以搜索成本超过 15% 的操作？

当 SQL Server 索引被删除（假设它是重复的）时，引擎采取哪些步骤来清除并重建引用它的执行计划？特别是我想知道它是一个一次性的过程，一个新的查询发生过程还是介于两者之间的过程。谢谢。

以下查询在约 60 个数据库上并行运行。在没有提示的情况下，至少 10% 的数据库存在大量溢出和非最佳计划。

使用更大的数据库作为指导，查询被锁定并带有提示（1 个 CPU 上约 75 毫秒），以减少运行时的差异，因为 1 个错误的计划会导致整体运行时间终止。我们主要反对让每个DB自由调整其计划，因为从长远来看，某些DB可能会在生产平台上着火。我们对大型数据库的近乎最佳计划感到非常满意，但对于较小的数据库可能不是最佳的。

即使在添加带有完整扫描的统计信息后，一些（~5）较小的数据库仍然表现出小的 1 级溢出（参见计划）。运行时间仍然可以（125 毫秒），但希望消除溢出。

这是 Sql Server 2019。自适应授权功能 (2017) 是否应该因溢出而调整授权？在 SSMS 和查看计划中重复运行它似乎表明没有变化。

select top (@pMax)
           aig.ObjectId,  
           iif((@pA in (1, 2, 3, 4, 5, 6, 9, 11, 12) and ttm.ObjectId is not null) or
               (@pA in (7, 8, 10, 13, 14, 15)), 1.0, 0.0) as Rank
      from oav.value aig               
      inner merge join Pub.CachedObjectHierarchyAttributes coha
        on coha.ObjectId = aig.ObjectId
       and coha.IsActiveForPublisher = 1
       and coha.IsToolItem = 1
      inner merge …

请参阅https://www.brentozar.com/pastetheplan/?id=SyLQIPDtF (SQL 2016 Enterprise)上的执行计划

• 我有一个数据仓库表peak_reporting_data，它跟踪每天和每小时的活动，每月包含大约 40 亿行，并具有按 date_key 分区的聚集列存储索引（每天一个分区）
• 在表peak_reporting_monats_peaks中，我聚合了该表并按月峰值对其进行排序/排名。有 3 种类型的活动 (kpi_type)，每种类型每月最多有 24 小时 * 31 天 = 744 行，[monats_peak] 排名从 1 到 744。它有一个关于 Month_key、kpi_type、monats_peak 的唯一索引。
• 对于最活跃的时间（每个 kpi_type），我需要更多详细信息，因此我编写了以下查询/视图：

    SELECT prmp.month_key
         , prd.*
      FROM mba.peak_reporting_monats_peaks        AS prmp
      LEFT LOOP JOIN (SELECT prd.date_key
                           , prd.hour
                           , prd.kpi_type
                           , prd.is_dr_brand
                           , prd.type_id_usage
                           , prd.product_identifier
                           , SUM(prd.kb) / 1024.0 / 1024.0 AS gb
                           , SUM(CAST(prd.sek AS BIGINT))  AS sek
                           , SUM(prd.anzahl)               AS anzahl
                           , SUM(prd.kb) / 439453125.0     AS gbits
                        FROM db1.mba.peak_reporting_data AS prd …

完整的实际计划在这里。

在执行计划之前（因为我正在调试一个运行不佳的计划），我有这个变量赋值块：

DECLARE @Days INT = 180
DECLARE @DateRangeFrom DateTime = DATEADD(d, -@Days, getDate())
DECLARE @DateRangeTo DateTime = getDate()
DECLARE @FacilityID INT = 1010
DECLARE @Answer0 INT = 1879
DECLARE @Answer1 INT = 1949
DECLARE @Answer1SetID INT = 1607
DECLARE @Answer2 INT = 1907
DECLARE @Answer2SetID INT = 1593

我的第一个问题是在 IRItemAnswer_Info 表（节点 ID 19）上执行的查找。它溢出到 Tempdb，它已经以错误的方式开始查询。它引用IRItemAnswerInfo_DGItemID_AnswerSourceID索引，这是正确的索引，因为我正在匹配DGItemID和AnswerSourceID，然后返回IncidentID。索引创建为

CREATE NONCLUSTERED INDEX IRItemAnswerInfo_DGItemID_AnswerSourceID
ON dbo.IRItemAnswer_Info (DGItemID, AnswerSourceID) 
INCLUDE([IncidentID], [AnswerBoolean])

但是，查询的估计行数为 53,459，实际行数为 969,812。

我刚刚完成强制通过新的统计数据UPDATE STATISTICS IRItemAnswer_Info …

我在查询存储中强制执行了一个计划，如下所示

EXEC sys.sp_query_store_force_plan @query_id = 113366, @plan_id = 3687662

但是当我再次运行查询时，查询不使用该计划，也不显示failure_force_reason

以下查询显示该计划已被强制，并表明上次运行时强制没有失败

SELECT  plan_id,
        query_id,
        is_forced_plan,
        last_force_failure_reason_desc
FROM    sys.query_store_plan
WHERE   is_forced_plan = 1

以下查询显示了相关查询的最后一次运行时间，这向我证实，我确实重新运行了这个查询，并且它使用了与我强制执行的计划不同的计划：

SELECT  TOP 1
        q.query_id,
        p.plan_id,
        s.last_execution_time,
        SYSDATETIMEOFFSET() AS CurrentTime
FROM    sys.query_store_query q
        JOIN sys.query_store_plan p
            ON q.query_id = p.query_id
        JOIN sys.query_store_runtime_stats s
            ON s.plan_id = p.plan_id
WHERE   q.query_id = 113366
ORDER BY s.last_execution_time DESC

为什么查询存储似乎忽略了这个计划的力量？我可以利用任何扩展事件或其他故障排除工具来了解吗？

我有一个经常更新影响某些几何图形的事件的表。几何区域是固定的，但可能有一个事件同时影响多个区域，因此两者之间存在多对多的关系。单个区域也可能同时受到多个事件的影响。

例如：

这些区域在我的表中表示为 ID 值。我需要在空间上表示这些值，因此我需要将这些值连接到包含s 和几何图形的event_id and area_id查找表。area_id不幸的是，这些表位于同一 SQL Server 2014 实例上的两个独立数据库中。

问题是这个连接过程非常慢；返回 18k-24k 行需要 90 秒到 3 分钟不等，具体取决于当前有多少事件处于活动状态。几何查找表包含 84k 行。

事件表结构（为了简单起见，删除了一些附加列）：

USE Events_DB;
CREATE TABLE [dbo].[Events](
    [EVENTS_ID] [bigint] NOT NULL,
    [AREA_ID] [bigint] NOT NULL,
    [START_DATE_TIME] [smalldatetime] NULL,
    [END_DATE_TIME] [smalldatetime] NULL,
 CONSTRAINT [PK_Events] PRIMARY KEY CLUSTERED 
(
    [EVENTS_ID] ASC,
    [AREA_ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS …

我试图了解 SQL Server 如何估计下面的 Stack Overflow 数据库查询的基数

首先，我创建索引

CREATE INDEX IX_PostId ON dbo.Comments
(
    PostId
)
INCLUDE
(
    [Text]
)

这是查询：

SELECT  u.DisplayName,
        c.PostId,
        c.Text
FROM    Users u
        JOIN Comments c
            ON u.Reputation = c.PostId
WHERE   u.AccountId = 22547

执行计划在这里

首先，SQL Server 扫描用户表上的聚集索引以返回与 AccountId 谓词匹配的用户。我可以看到它使用了这个统计数据：_WA_Sys_0000000E_09DE7BCC

我可以看到该用户没有范围高键，因此 SQL Server 使用 avg_range 行并估计 1

评论索引搜索的搜索谓词是

soScalar Operator([StackOverflow2010].[dbo].[Users].[Reputation] as [u].[Reputation]表示users表中accountId为的用户的信誉值22547

我可以看到总共加载了三个统计数据：

_WA_Sys_0000000E_09DE7BCC- Users.AccountId（用于估计聚集索引查找谓词）

IX_PostId- Comments.PostId（用于估计索引查找谓词）

_WA_Sys_0000000A_09DE7BCC- 用户.声誉 (?)

SQL Server 如何得出索引查找的估计值？它无法在编译时知道 accountId 的信誉，22547因为帐户 …

在 Azure SQL 数据库（SQL2019 兼容）上，我有一个 ETL 进程，它以 DeltaTrack 模式填充 HISTORY 表。

在 Proc 中，有一个对 HISTORY 表的更新，查询引擎正在使用 SORT，但我有一个应该覆盖它的索引。

此 UPDATE 的用例是针对现有行，自从该行首次添加到 HISTORY 表中以来，我们已向摄取添加了额外的列。

这种排序会导致我们更大/更宽的表上的更新速度极其缓慢。

如何调整索引或查询以删除查询 3中的排序？

DROP TABLE IF EXISTS dbo.STAGE;
GO
CREATE TABLE dbo.STAGE
(
    Id varchar(18) NULL,
    CreatedDate varchar(4000) NULL,
    LastModifiedDate varchar(4000) NULL,
    LastReferencedDate varchar(4000) NULL,
    [Name] varchar(4000) NULL,
    OwnerId varchar(4000) NULL,
    SystemTimestamp datetime2(7) NULL
)
GO

DROP TABLE IF EXISTS dbo.HISTORY;
GO
CREATE TABLE dbo.HISTORY
(
    HistoryRecordId int IDENTITY(1,1) …