标签: execution-plan

以下查询转换表示 13k 行 x 2 列的打包 CSV 的单个字符串。A 列是一个 bigint。B 列是一个smallint。

declare
    @dataCsv nvarchar(max) = '29653,36,19603,36,19604,36,29654,36';  -- abbreviated, actually 13k rows

  with Input as
  (
      select Value,
             Row = row_number() over (order by (select null)) - 1
      from string_split(@dataCsv, ',') o
  )
  --insert into PubCache.TableName
  select 78064 as CacheId,
         convert(bigint, i.Value) as ObjectId,
         convert(smallint, i2.Value) as BrandId
    from Input i
    inner hash join Input i2    -- hash to encourage string_split() only once per column
      on i2.Row = i.Row + 1 …

我正在使用托管数千个数据库的 SQL Server 实例。每个数据库对应不同的客户，但它们都共享相同的模式。

最近，我观察到许多查询具有相同的查询哈希。经过进一步调查，我发现虽然查询具有相同的文本，但它们是针对不同的数据库执行的。

据我了解，由于每个查询的上下文都是特定于数据库的，因此重复的查询哈希是可以预料的。不过，我很想知道我的理解是否正确。

此外，我有兴趣探索优化此设置的选项。具体来说，是否有一种方法可以整合不同数据库之间相同查询的执行计划，或者由于不同的数据库上下文而无法实现这一点？

任何有关此事的见解或建议将不胜感激。

预先感谢您的帮助！

这是在 SQL 2005 SP2 上，但我怀疑这通常适用于所有查询提示。

我有一个临时的 sql 语句，它仅仅因为 OPTION（重新编译）而获得不同的查询计划。批处理语句永远不会（实际上）被重用，因为它使用非参数化动态 sql 生成，其中语句随日期/其他参数而变化。我已经通过检查缓存的 plan_handle 确认了这种情况，在批量更改时总是使用不同的 ID。

当我执行 dbcc freeproccache 时，我希望我为语句获得的查询计划与添加了“选项（重新编译）”查询提示的查询计划完全相同。但它不是，它实际上完全不同（要快得多）。

有谁知道为什么添加查询提示会导致引擎选择不同的查询计划？

声明是这样的

dbcc freeproccache
go
sp_executesql ' 
declare @begindate datetime
declare @enddate datetime
select @begindate='1/1/2011'
select @enddate='2/1/2011'
select count(*) from tableA where tableA.datecolumn between @begindate and @enddate 
and exists( 
select A
union all select B
union all select C
)'

我所要做的就是更改语句以使用重新编译查询提示，然后我会得到不同的（更好的）查询计划。

dbcc freeproccache
go
sp_executesql ' 
declare @begindate datetime
declare @enddate datetime
select @begindate='1/1/2011'
select @enddate='2/1/2011'
select count(*) from tableA where tableA.datecolumn …

如果我在我们的生产服务器上运行以下查询：

SELECT DISTINCT TOP 10
t.TEXT QueryName,
s.execution_count AS ExecutionCount,
s.max_elapsed_time / 100000 AS MaxElapsedTime,
ISNULL(s.total_elapsed_time / s.execution_count, 0) / 100000 AS AvgElapsedTime,
s.creation_time AS LogCreatedOn,
ISNULL(s.execution_count / DATEDIFF(s, s.creation_time, GETDATE()), 0) AS FrequencyPerSec
,s.plan_handle, s.plan_generation_num
FROM sys.dm_exec_query_stats s
CROSS APPLY sys.dm_exec_sql_text( s.sql_handle ) t
ORDER BY
s.max_elapsed_time / 100000 DESC

我的主要查询是“创建过程.......”这是否意味着 sql server 重新编译这个存储过程不止一次？

下面是一个存储过程，用于计算一个月内制作的小部件数量。如果没有制作小部件，则不存在任何记录。

执行计划显示INNER JOIN了 M 和 A 表中的一个，在语句中我正在执行一个LEFT OUTER JOIN.

我想计算一个时间范围内制作的小部件数量，将其加入月份表（1 月至 12 月），并将结果显示在 SSRS 报告中。加入是因为我无法获得不存在的COUNT数据。目前我得到：

MonthName   Widget Count
February    2
March       3
April       4
May         6
June        5
July        4 
August      6
September   2
October     4
November    1
December    2

我希望列表中没有包含小部件的月份。

这是代码：

DECLARE @OName varchar(50)
DECLARE @Start_Date DATE 
DECLARE @End_Date DATE

SET @OName = 'John'
SET @Start_Date = '01/01/2012'
SET @End_Date   = '12/31/2012'

SELECT   M.[MonthName]
    ,COUNT(A.[Widget_ID]) AS 'Widget Count'
FROM [Connector].dbo.[Months] AS M 
        LEFT …

给定两个 Microsoft SQL 服务器：

假设ServerA有一个名为“View1”的视图： SELECT * FROM ServerB.database.dbo.Table1 WHERE Column1 IN (1,2,3)

和一个存储过程“sp_Foo”： SELECT * FROM View1 WHERE Column1=1

当我执行时EXEC sp_Foo，哪个查询在哪个服务器上执行？都是在ServerB上执行的吗？都在 ServerA 上？还是在ServerB上执行的视图查询和在ServerA上执行的SP查询？

在调查性能问题时，一位同事建议运行 DBCC FREEPROCCACHE 来清除计划缓存。在注意到重启后性能有所提高后，他得出了这个结论。

这感觉像是一种相当快速和肮脏的方法 - 有没有更确定、更明确的方法来确定清除计划缓存是否是最好的方法？做出这个决定的错误可能会导致性能问题。

如果这个问题太模糊，请道歉:)

谢谢！

通过将计划保存在文件中，我并不是要查看它，而是强制优化器使用保存的计划来执行某些查询。

例如，如果优化器选择对两表查询进行哈希连接，而我设法强制优化器使用嵌套循环连接，是否有任何方法可以保存嵌套循环连接计划并让优化器接下来使用它我执行相同查询的时间？

我有一些运行缓慢的查询（按月分组的 100 万条记录中的 8 秒），并且一直试图理解执行计划。我们使用大约 10 个 TVP 来发送一组用户选择的过滤器，我有一个索引视图，占查询成本的 84%。

执行计划比较大，不能上传到这里，所以上传到这里了

我花了很多时间来尝试优化这些查询（其中有 14 个，但每个查询的核心都大同小异）并且希望任何人在阅读它们时提出建议或提示。我还实现了实际执行计划建议的查询，但查询速度慢了 5 倍？

我正在使用 Postgres 9.1 我要加入两个表：

wikidb=> \d page
                         Table "public.page"
        Column         |     Type      |          Modifiers           
-----------------------+---------------+------------------------------
 page_id               | bigint        | not null
 page_namespace        | integer       | not null default 0
 page_title            | text          | not null default ''::text
 [...]
Indexes:
    [...]
    "page_page_namespace_page_title_idx" UNIQUE, btree (page_namespace, page_title)

wikidb=> \d pagelinks
                 Table "public.pagelinks"
      Column       |  Type   |         Modifiers          
-------------------+---------+----------------------------
 pl_from           | bigint  | not null default 0::bigint
 pl_namespace      | integer | not null default 0
 pl_title          | text    | not null default ''::text …