标签: execution-plan

我有一个这样的查询：

select dbo.fn_complexFunction(t.id)
from mytable t

在SQL Sentry Plan Explorer 中，我注意到我必须运行 Get Estimated Plan 才能使查询计划包含 UDF。

运行“获取实际计划”时，逻辑读取和其他指标似乎不包括 UDF 中发生的操作。在这种情况下，使用 Profiler 是唯一的解决方法吗？

我们最近遇到了临界点问题，我们的一些报告查询过去需要在几秒钟内完成执行，现在需要超过 2 分钟，因为查询优化器只是忽略了搜索列上的非聚集索引。下面是一个示例查询：

select top 100 *
from   [dbo].[t_Call]
where  ID > 0 
  and  throwtime between '3/20/2014 7:00:00 AM' and '3/24/2014 6:59:59 AM'
order by id

该ID列是聚集索引并且Throwtime具有非聚集索引。在这种情况下，我们注意到 ordering bythrowtime而不是ID更改查询计划和非聚集索引被使用。我们还计划存档一些旧数据（它目前有 2000 万行！！）。但是在应用程序中进行这些更改需要一些时间，我需要找到一种方法来使报告运行得相当快，而无需在应用程序级别进行更改（哦，这就是生活！）。

进入计划指南。我使用非聚集索引查询提示创建了以下计划指南，但出于某种原因，仍未使用非聚集索引。我错过了什么吗？

EXEC sp_create_plan_guide 
@name = N'[prod2reports_callthrowtime]', 
@stmt = N'select top 100 *
          from   [dbo] . [t_Call]
          where  ID > @0 and @1 < = ThrowTime and ThrowTime < = @2 order by ID',
@type = N'SQL', 
@module_or_batch = N'select …

我在加载 PostgreSQL 9.3.4 时遇到了一些与 StackOverflow 模式相关的数据的问题。我有一个查询比它应该花费的时间长大约 10 倍，因为它选择使用散列连接而不是带有索引的嵌套循环。例如，如果我在查询中选择 500 个用户，则使用散列连接而不是使用 post_tokenized 表上的 id 和类型索引：

explain 
select creation_epoch, user_screen_name, chunk from post_tokenized as tokenized_tbl
                    join posts as posts_tbl
                    on posts_tbl.id = tokenized_tbl.id
                    where type = 'tag'
                    and user_screen_name is not null
                    and owner_user_id in (select id from users where reputation > 100000 order by reputation asc limit 500)
                    and tokenized_tbl.id in (select id from posts where owner_user_id in (select id from users where reputation > 100000 order by reputation asc limit …

我有一个 PostgreSQL 9.3 表，其中包含一些数字和一些附加数据：

CREATE TABLE mytable (
    myid BIGINT,
    somedata BYTEA
)

该表目前有大约 10M 条记录，占用 1GB 磁盘空间。myid不连续。

我想计算 100000 个连续数字的每个块中有多少行：

SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;

这将返回大约 3500 行。

我注意到某个索引的存在显着加快了这个查询，即使查询计划根本没有提到它。没有索引的查询计划：

db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=1636639.92..1709958.65 rows=496942 width=8) (actual time=6783.763..8888.841 rows=3460 loops=1)
   Output: ((myid / 100000)), count(*)
   ->  Sort  (cost=1636639.92..1659008.91 rows=8947594 width=8) (actual time=6783.752..8005.831 …

当我运行此删除时：

DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870

...它删除了 39,157 行。它应该很简单，因为它是在 ETLHeaderID 上删除的，它是聚集索引和主键。但是（根据执行计划）它似乎达到了 361,190 行并使用了其他索引。该表确实有一个具有 XML 数据类型的字段（以防影响此 DELETE）。

任何想法为什么以及如何加速此 DELETE？

此处的执行计划： http ://sharetext.org/qwDY 此处的表架构：http : //sharetext.org/Vl9j

谢谢

我们正在使用分区来减少由于锁定而阻塞我们 OLTP 系统体验的数量，分区方案根据客户 ID 将工作表拆分为 100 个分区。然而，我们在测试过程中发现执行计划的选择方式并不完全符合我们的预期。

测试场景是具有 300,000 条联系人记录的单个客户（每个联系人的数据分布在两个表中），所有记录都位于单个分区中，并通过查询在客户分区中查找 500 条特定行。您会期望像哈希匹配这样的东西来消除不需要的 299,500 以在计划的早期启动，但看起来 SQL Server 选择获取整个表的记录数并在考虑如何之前对所有分区进行平均它将处理许多记录，这导致它选择嵌套循环并在该过程的后期消除不需要的记录。通常，对于非分区表进行相同查询所需的时间是其 9 倍。

奇怪的是，向选择添加一个选项（重新编译）给出了一个明智的计划，但我不知道为什么这会有所作为。这不是存储过程，在测试期间，我们在每次测试运行之前清除过程缓存。

当所涉及的表未分区时，不会看到此行为，即每次选择适当的计划，因为估计的行数与实际数相匹配

对这种行为的任何见解将不胜感激。

架构设置：

USE [Scratch]
GO
CREATE SCHEMA part
GO
CREATE PARTITION FUNCTION [ContactPartition](smallint) AS RANGE LEFT FOR VALUES (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, …

在 SQL Server 2012 中，我有一个表值函数，它连接到另一个表，我需要计算这个“表值函数”的行数。当我检查执行计划时，我可以看到左连接表。为什么？左连接表如何影响返回的行数？我希望数据库引擎不需要在 SELECT count(..) 查询中评估左联合表。

Select count(realtyId) FROM [dbo].[GetFilteredRealtyFulltext]('"praha"')

执行计划：

表值函数：

CREATE FUNCTION [dbo].[GetFilteredRealtyFulltext]
(@criteria nvarchar(4000))
RETURNS TABLE
AS
RETURN (SELECT 
realty.Id AS realtyId,
realty.OwnerId,
realty.Caption AS realtyCaption,
realty.BusinessCategory,
realty.Created,
realty.LastChanged,
realty.LastChangedType,
realty.Price,
realty.Pricing,
realty.PriceCurrency,
realty.PriceNote,
realty.PricePlus,
realty.OfferState,
realty.OrderCode,
realty.PublishAddress,
realty.PublishMap,
realty.AreaLand,
realty.AreaCover,
realty.AreaFloor,
realty.Views,
realty.TopPoints,
realty.Radius,
COALESCE(realty.Wgs84X, ruian_cobce.Wgs84X, ruian_obec.Wgs84X) as Wgs84X,
COALESCE(realty.Wgs84Y, ruian_cobce.Wgs84Y, ruian_obec.Wgs84Y) as Wgs84Y,
realty.krajId,
realty.okresId,
realty.obecId,
realty.cobceId,
IsNull(CONVERT(int,realty.Ranking),0) as Ranking,

realty.energy_efficiency_rating,
realty.energy_performance_attachment,
realty.energy_performance_certificate,
realty.energy_performance_summary,

Category.Id AS CategoryId,
Category.ParentCategoryId,
Category.WholeName,
okres.nazev AS …

我使用 Adam Machanic 的出色sp_WhoIsActive过程来查看活动并记录到表中以对长时间运行的查询进行故障排除。

为什么执行计划没有一直显示在结果中？大多数情况下，该query_plan值为 NULL。如果我查看结果中的SQL_TEXT列，我会看到带有参数但没有值的查询，如下所示：

(@P0 nvarchar(4000),@P1 nvarchar(4000))
select blah from foo where a = @P0 and b = @P1 

执行计划未显示在此处时如何获取它们？他们为什么不显示？我必须使用 Profiler 或扩展事件吗？将虚拟值放入这些参数并运行包含实际执行计划的查询是否会生成与我记录时实际使用的计划相同的计划？

我已经与供应商确认他们正在使用 Hibernate 3.5。

我试图回答这个问题，说明 from 子句是可选的。

如您所见，查询计划中有 BMK 运算符，但没有指示显示它是如何计算的。

到目前为止
我尝试过的步骤：我开始使用 BMK1000 进行搜索，但它显示了一堆使用相同运算符的问题。最后我找到了一个线程，上面写着“您所引用的 BMK 是堆中的存储位置，被保留使用非聚集索引而不是簇键。”..但不确定这与我有什么关系，因为我没有任何索引..

问：
什么是 BMK 运算符以及它是如何计算的。任何指针也会有所帮助

这是重现问题的SQLFiddle

我有一个简单的SELECT声明。

USE [AdventureWorks2014]
GO

SELECT *
FROM Sales.SalesOrderDetail sod

执行计划有两个Compute Scalar.

为什么是这样？我原以为只得到Index Scan或者Table Scan?

第一个（最右边的）有

 [[AdventureWorks2014].[Sales].[SalesOrderDetail].LineTotal] = Scalar Operator(isnull(CONVERT_IMPLICIT(numeric(19,4),[AdventureWorks2014].[Sales].[SalesOrderDetail].[UnitPrice] as [sod].[UnitPrice],0)*((1.0)-CONVERT_IMPLICIT(numeric(19,4),[AdventureWorks2014].[Sales].[SalesOrderDetail].[UnitPriceDiscount] as [sod].[UnitPriceDiscount],0))*CONVERT_IMPLICIT(numeric(5,0),[AdventureWorks2014].[Sales].[SalesOrderDetail].[OrderQty] as [sod].[OrderQty],0),(0.000000)))

当第二个有：

[[sod].LineTotal] = Scalar Operator([AdventureWorks2014].[Sales].[SalesOrderDetail].[LineTotal] as [sod].[LineTotal])