标签: execution-plan

我想知道是否有人可以阐明我的担忧，即query_plan_hash碰撞可能导致查询作为完全不同的查询执行。

散列是一个 16 位的十六进制，sp_help sys.dm_exec_query_stats表示是一个二进制。因此它只是一个 64 位的散列，并且碰撞似乎很有可能（考虑到 SHA1 [160 位] 刚刚被验证有碰撞）。

请问plan_hash并query_plan_hash都有碰撞的这个（查询作为一个完全不同的查询被执行）的情况发生？

我也很好奇 SQL Server 中是否有设置允许我们将此哈希更改为 SHA2-512（以减少发生冲突的可能性）。我们的数据非常重要。

我通过 Google 和 Stack Exchange 论坛进行了高低搜索。

我有两个表：

create table animal
(
    aid integer,
    cid integer,
    aname varchar(255) default NULL::character varying,
    species text
);

create table daily_feeds
(
    aid integer,
    zid integer,
    shift integer,
    menu integer
);

和一个查询：

SELECT
aname,
shift
FROM animal
NATURAL JOIN daily_feeds
WHERE menu = 1;

餐桌动物包含大约 40000 行，表 daily_feeds 包含大约 80000 行，每只动物 2 行。

我认为在用于连接animal.aid和daily_feeds.aid的列上添加索引可能会导致不同的执行计划并提高性能。

create index aaid on animal (aid);

create index daid on daily_feeds using btree (aid);

这不会发生。这是为什么？

显然，这是一个非常简单且学术性的示例，我试图用它来了解有关数据库查询优化的更多信息。

编辑：

添加没有索引时的执行计划：

Hash Join  (cost=1439.24..2488.23 rows=499 width=10) …

我有一个要优化的查询，如下所示：

SELECT 1 FROM HugeView
WHERE (Col1 = 'a' AND @val = 1) OR (Col2 = 'a' AND @Val = 0)

(where Col1 and Col2 are on different tables)

如果我对@Val值 (1/0) 进行硬编码- SQL Server 知道构建一个执行计划，在该计划中它只访问Col1或的相关表Col2。

但是当使用一个变量时，所有的表都会HugeView被访问。

您能否建议一种可以帮助 SQL Server 不访问不必要表的方法？

限制：

• 不能用 option (recompile)
• 无法将此代码封装在 SP 中
• 无法改变 HugeView

不幸的是，上述所有限制都是产品设计和/或开发范围的一部分——我对此无能为力——只能在我拥有的范围内工作。

但是，我知道它@var是 1 或 0，并且可以根据需要创建和查询（并加入）临时表或“真实”表。

另请注意，我没有从Col1or的表中进行选择Col2- 我仅将它们用于过滤。

我尝试在空表上创建和加入，或者top(@somevar)根据@var的值 - 但没有帮助。

UNION ALL不会有帮助，因为在任何情况下优化器都不知道 …

有什么办法可以优化FOR XML PATH语句吗？或者也许我应该使用另一种方法？

目前的方法根本不可接受。这需要几分钟。我知道视图是一个非常大的联盟，需要时间来消耗它，但也许是另一种方式......

这是查询：

SELECT t.serialNumber as TVM
  ,[issuanceDate] as transactionDate
  ,ioy.tvmTransactionId as TVM_TRANS_ID
  ,STUFF((SELECT ', ' + stv.carrierSN
    FROM HERMES.wts.v_SaleTransactionView as stv
    WHERE stv.tvmTransactionId = ioy.tvmTransactionId
    and stv.serialNumber = 'M040'
    FOR XML PATH ('')), 1, 2, '') as [serial_numbers]
  FROM [hermes].[wts].[IOYLog] ioy
  left join Hermes.hermes.Terminals t on ioy.tp_terminalId = t.tp_terminalId
  left join hermes.hermes.POS p on t.tp_POSId = p.tp_POSId
  left join [Hermes].[wts].[IOUPaymentStatus] [is] on [is].[tp_paymentStatusId] = ioy.status
  WHERE [is].includeInReports = 1 
  and (issuanceDate BETWEEN '2017/09/01' AND '2017/09/08') …

我需要你的帮助，我需要一些指导来提高以下给定视图的性能。

我有一个用以下代码编写的视图：

with timeframes  as
(
select p.SEARCH_NUM, 
case   when p.FROM_DATE is not null then p.FROM_DATE
       when p.FROM_DATE is null and P.SEARCH_DAYS is not null and p.TO_DATE is not null then DATEADD(day,p.SEARCH_DAYS*-1,p.TO_DATE)
       when p.FROM_DATE is null and P.SEARCH_DAYS is not null and p.TO_DATE is null then DATEADD(day,p.SEARCH_DAYS*-1,GetDate()) 
       when p.FROM_DATE is null and P.SEARCH_DAYS is null and p.TO_DATE is not null and p.DURATION = 'Yearly' then DATEADD(year,-1,p.TO_DATE)
       when p.FROM_DATE is null and P.SEARCH_DAYS is null and p.TO_DATE is null and p.DURATION …

我在另一个论坛上遇到了这个：

PG 对于IN查询中的值的限制为 100，之后不使用所述列上的索引。例如：SELECT ... WHERE IN (...)如果 IN 列表超过 100，则对 PK的典型查询将变成全表扫描。

我无法找到任何关于此的信息。PG 有没有这样的限制（我是这么想的），如果有，这个限制是多少？

我知道有时在临时表中使用大型子选择会更好，但是了解截止位置会很有帮助。

请帮我解释这个声明和计划：

https://www.brentozar.com/pastetheplan/?id=Bysy6YtEV

我们从 Oracle 迁移到 SQL Server，我们有一些非常奇怪的行为。它可能与迁移过程中的问题有关。

我发现很难解释执行计划。两种环境都应该具有相同的结构和索引。统计数据应该是最新的。SQL Server 中的设置：

• 启用创建自动统计
• 针对 Ad Hoc 查询进行优化 = true
• 启用快照隔离
• 最大平行 = 4
• 阈值 50

DB 大小为 600 Gb，16 核，160 Gb 内存。

查询：

SELECT
    COUNT ( t_01.rsecondary_objectu ) AS selectExpr
FROM
    PIMANRELATION t_01 ,
    PITEM t_02 ,
    PITEMREVISION t_03
WHERE
    (   (   (   ( t_01.rprimary_objectu = t_02.puid )
            OR  ( t_01.rprimary_objectu = t_03.puid )
            )
       AND
            ( t_01.rrelation_typeu = 'w8INy241VJFL2B' )
        )
   AND  t_01.rsecondary_objectu = '2yLJkWqiVJFL2B'
    )

甲骨文

我们发现问题是相关的，并且取决于数据。如果我选择一个不同的项目在 GUI 中复制（它实际上是一个复制的东西以及应用程序如何执行这些语句），它会立即工作。查询然后一旦工作正常看起来有点不同：https …

我们的系统通过大量测试生成 SQL。我怀疑在某些情况下，找到理想的执行计划需要很长时间。所以 SQL 只选择它迄今为止找到的最好的计划，然后需要很长时间才能运行。是否可以增加 SQL 搜索最佳计划的时间？

偶尔（但不常见）我的 SQL 服务器会花费看起来很奇怪的时间来生成执行计划。为以下相当简单的查询生成估计的执行计划只花了 37 秒：

SELECT *
FROM Table1
WHERE IndexedIntField1 = 12345
    AND NonIndexedVarcharField IN ('Value1', 'Value2', 'Value3')

这个查询的结果数量大约为 500 行（来自一个包含大约 100 亿行的表），执行计划本质上是一个非聚集索引查找和键查找。

这是正常的吗？

编辑：

• 表 1 是一个实际的物化常规基于磁盘的表（这里没有什么特别的）。
• 它大约有 30 列宽。
• 上面有 1 个聚集索引和 4 个非聚集索引。
• 我的示例中的“IndexedIntField1”是 2 个非聚集索引中索引键的一部分，并且是第三个非聚集索引上的包含列。
• “NonIndexedVarcharField”不是键，也不包含在任何索引中。
• 我们每周至少更新一次表和索引的统计信息（有时一天一次或更多次）
• 此表上没有花哨的计算列
• 表上的索引非常简单，键列/包含列中只有几个字段，除了将“IndexedIntField1”作为键列的索引之一确实包含大约 15 列（因此它是一个相当大的索引） ）。

我们在具有 8 个套接字和 20 个处理器的 VM 上托管了一个 UAT3 服务器，我们在具有相同配置的同一 VM 上托管了类似的 UAT2 服务器。

我们在两个服务器上运行以下查询

select recid from Table1 where nation='AE'

两个服务器具有相同的数据和相同的结构。

UAT2 和 UAT3 具有默认设置并行度5 和最大并行度的成本阈值0。

select recid from Table1 where nation='AE'

CREATE TABLE [dbo].[FKMB_CUSTOMER]( 
    [RECID] [nvarchar](64) NOT NULL, 
    [XMLRECORD] [xml] NULL, 
    [ALT_CUSTOMER] AS 
        ([dbo].[IX_CUSTOMER_ALT_CUSTOMER]([XMLRECORD])) 
        PERSISTED, 
    [SMS] AS 
        ([dbo].[IX_CUSTOMER_SMS_1]([XMLRECORD])) …