Questions tagged «execution-plan»

我有一个分区视图，具有下面的插入触发器（可怜的芒分区）。当我执行DELETE时，我得到以下查询计划： delete from factproductprice where pricedate = '20170725' 在视图上触发： ALTER TRIGGER [dbo].[factProductPriceDelete] ON [dbo].[FactProductPrice] INSTEAD OF DELETE AS BEGIN IF @@ROWCOUNT = 0 RETURN; DECLARE @PriceDate DATE SELECT @PriceDate = CAST(PriceDate AS DATE) FROM DELETED IF @PriceDate BETWEEN '20140101' AND '20141231' BEGIN DELETE FROM dbo.FactProductPrice2014 WHERE ProductId IN (SELECT ProductId …

9 sql-server  sql-server-2014  trigger  partitioning  execution-plan 

在分区上进行联接与在整个表上进行联接时，以下联接具有非常不同的行估计： CREATE TABLE m_data.ga_session ( session_id BIGINT NOT NULL, visitor_id BIGINT NOT NULL, transaction_id TEXT, timestamp TIMESTAMP WITH TIME ZONE NOT NULL, day_id INTEGER NOT NULL, [...] device_category TEXT NOT NULL, [...] operating_system TEXT ); 对于所有分区： CREATE TABLE IF NOT EXISTS m_data.ga_session_20170127 ( CHECK (day_id = 20170127) ) INHERITS (m_data.ga_session); …

9 postgresql  execution-plan  postgresql-9.5 

将常规列转换为持久计算列会导致此查询无法执行索引查找。为什么？ 在多个SQL Server版本上进行了测试，包括2016 SP1 CU1。 复制 使用计算列 带有常规列 麻烦的是table1，col7。 表格和查询是原始文档的部分（简化）版本。我知道查询可以用不同的方式重写，并且出于某种原因可以避免该问题，但是我们需要避免触摸代码，而为什么table1找不到原因仍然存在。 正如保罗·怀特（Paul White）所展示的（谢谢！），寻道在强制的情况下仍然可用，所以问题是：为什么寻道未由优化程序选择，以及我们是否可以做一些不同的事情来使寻道按原样进行而不改变？码？ 为了澄清有问题的部分，以下是不良执行计划中的相关扫描：

9 sql-server  optimization  execution-plan 

我知道使用索引或表扫描时，SQL Server使用统计信息来查看哪个更好。 我有一个2000万行的表。我在（SnapshotKey，Measure）上有一个索引，并且此查询： select Measure, SnapshotKey, MeasureBand from t1 where Measure = 'FinanceFICOScore' group by Measure, SnapshotKey, MeasureBand 查询返回500k行。因此，查询仅选择表的2.5％的行。 问题是为什么SQL Server不使用我拥有的非聚集索引，而是使用表扫描？ 统计信息已更新。 值得一提的是查询性能还是不错的。 表扫描 强制索引 表/索引结构 CREATE TABLE [t1]( [SnapshotKey] [int] NOT NULL, [SnapshotDt] [date] NOT NULL, [Measure] [nvarchar](30) NOT NULL, [MeasureBand] [nvarchar](30) NOT NULL, -- and many more fields …

9 sql-server  sql-server-2012  index  optimization  execution-plan 

经过一会儿的搜索后，我决定发布此问题，因为它找不到答案，并向您道歉，如果那里没有类似的问题/答案。 在两个类似设置的SQL服务器上运行下面的查询时，我们会遇到不同的执行计划，这会影响性能，我们需要帮助找出原因。 查询： SELECT process_id INTO #temp FROM revrep_revenue_fact WHERE process_id = 284 DROP TABLE #temp 服务器A的执行计划 服务器B的执行计划 服务器B http://s2.postimg.org/z9fjrfv4n/server_B.png 您会注意到，服务器B在实际执行计划中具有TOP物理操作，我们正在尝试找出原因。两个查询在索引查找中使用相同的索引。 这是服务器A和服务器B的一些详细信息 服务器A和B都 Windows Server 2008 R2标准Service Pack 1 24GB RAM 64位操作系统 使用（SELECT SERVERPROPERTY（'ProductVersion'））获得的SQL Server 2012版本 服务器A SQL版本11.0.3000.0 服务器B SQL版本11.0.5058.0 我们尝试过的 清除过程缓存 重建索引 刷新统计 设置行数0 为什么服务器B在执行计划中有TOP？在这个简单的查询示例中，没有实际问题，但是在较大的查询中，TOP的成本增加了，我们发现性能受到了影响。我们将不胜感激调试任何帮助，我们将为您提供可能需要帮助的任何其他信息。

9 sql-server  sql-server-2012  performance  execution-plan 

在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 …

9 sql-server  execution-plan  count 

我有一个奇怪的情况。使用sp_whoisactive我可以看到： 好的，通过此查询，我可以看到触发了什么（此单词在英语中存在吗？）： SELECT c.session_id, c.properties, c.creation_time, c.is_open, t.text FROM sys.dm_exec_cursors (SPID) c --0 for all cursors running CROSS APPLY sys.dm_exec_sql_text (c.sql_handle) t 结果： 这很简单select。为什么使用f etch_cursor？ 另外，我也看到很多“空白”的sql_texts。这个“光标”有什么用吗？ DBCC INPUTBUFFER (spid) 告诉我这个： 有这个问题 在这里（我做的），但我不知道这是否是同样的事情。 编辑1： 使用kin提供的查询，我看到以下内容： 编辑2： 使用活动监视器，可以看到以下内容： 这是最昂贵的查询（第一个查询是有意的，我们知道）。 再一次，我想知道，为什么这select * from...是FETCH CURSOR... 的原因 编辑3： 此“ select * from...”正在从另一台服务器（通过linked server）运行。 好吧，现在我在理解@kin所说的内容时遇到了问题。 这是execution …

9 sql-server-2008  execution-plan  cursors  process 

当我运行此删除时： DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870 ...它删除39,157行。它应该很简单，因为它是在ETLHeaderID上删除的，而ETLHeaderID是聚簇索引和主键。但是（根据执行计划）它似乎达到361,190行并使用其他索引。该表确实具有XML数据类型的字段（以防影响此DELETE）。 有任何想法为何以及如何加快此DELETE？ 这里的执行计划： http ://sharetext.org/qwDY这里的表模式：http : //sharetext.org/Vl9j 谢谢

9 sql-server-2008  query-performance  execution-plan 

我有这样的查询： select dbo.fn_complexFunction(t.id) from mytable t 在SQL Sentry Plan Explorer中，我注意到我必须运行Get Estimated Plan才能使查询计划包括UDF。 运行“获取实际计划”时，似乎逻辑读取和其他指标未包括UDF中发生的操作。在这种情况下，是否是使用Profiler的唯一解决方法？

9 sql-server  sql-server-2008  query-performance  execution-plan  functions 

我有一个带有多个视图的架构。我需要检查执行计划，以确保适当的索引到位并正在使用。 我该怎么做呢？ 我宁愿不必复制输出并将其粘贴show create view <viewname>到中explain，尤其是因为某些视图是建立在其他视图之上的，这会很痛苦。

9 mysql  performance  execution-plan  view 

我有一条delete语句，在存储过程中运行时使用了错误的计划，但是在临时运行时选择了更好的计划。 我已经为查询使用的表重建了所有索引，并删除了所有缓存。优化器仍然为存储过程选择了错误的计划。 我想知道为什么优化器对存储过程使用的是与临时SQL不同的执行计划。 更新：我猜想它毕竟一定是参数-当我运行带有硬编码变量的临时代码时，我可以获得具有正确值的“坏”计划（这是一个日期，一个岁的值）似乎会产生“好的”计划）。现在继续尝试通过使用查询提示在proc上强制执行“良好”计划。 解决方案：我最终使用OPTIMIZE FOR UNKNOWN提示获得了想要的计划。

9 sql-server  execution-plan 

我有两个非常相似的查询 第一个查询： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' and a.TargetTypeId IN (1,2,3,4,5,6,7,8,9, 11,12,13,14,15,16,17,18,19, 21,22,23,24,25,26,27,28,29,30, 31,32,33,34,35,36,37,38,39, 41,42,43,44,45,46,47,48,49, 51,52,53,54,55,56,57,58,59, 61,62,63,64,65,66,67,68,69, 71,72,73,74,75,76,77,78,79) 结果：267479 计划：https：//www.brentozar.com/pastetheplan/？id = BJWTtILyS 第二个查询： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' …

9 sql-server  performance  query-performance  optimization  execution-plan 

我在SQL Server 2017执行计划中看到了以下警告： 警告：操作导致剩余IO [sic]。实际读取的行数为（3,321,318），但返回的行数为40。 这是SQLSentry PlanExplorer的片段： 为了改进代码，我添加了非聚集索引，因此SQL Server可以访问相关行。它工作正常，但通常索引中将包含太多（大）列。看起来像这样： 如果我仅添加索引，而没有包含列，则强制使用索引，如下所示： 显然，SQL Server认为密钥查找比剩余的I / O昂贵得多。我有一个没有大量测试数据的测试设置（但是），但是当代码投入生产时，它需要处理更多的数据，所以我很确定需要某种非聚集索引。 当您在SSD上运行时，关键查询真的那么昂贵吗？我必须创建全脂索引（包含很多包含列）吗？ 执行计划： https : //www.brentozar.com/pastetheplan/?id=SJtiRte2X这是一个长存储过程的一部分。寻找IX_BatchNo_DeviceNo_CreatedUTC。

9 sql-server  optimization  execution-plan  sql-server-2017  nonclustered-index 

我有一个支持.NET Core API应用程序的Azure SQL数据库。浏览Azure门户中的性能概述报告表明，我的数据库服务器上的大部分负载（DTU使用情况）来自CPU，特别是一个查询： 如我们所见，查询3780几乎负责服务器上的所有CPU使用率。 这有点说得通，因为查询3780（见下文）基本上是应用程序的整个关键所在，并且用户经常调用它。这也是一个相当复杂的查询，需要许多联接才能获得所需的正确数据集。该查询来自一个存储库，最终看起来像这样： -- @UserId UNIQUEIDENTIFIER SELECT C.[Id], C.[UserId], C.[OrganizationId], C.[Type], C.[Data], C.[Attachments], C.[CreationDate], C.[RevisionDate], CASE WHEN @UserId IS NULL OR C.[Favorites] IS NULL OR JSON_VALUE(C.[Favorites], CONCAT('$."', @UserId, '"')) IS NULL THEN 0 ELSE 1 END [Favorite], CASE WHEN @UserId IS NULL OR C.[Folders] IS NULL THEN …

9 sql-server  query-performance  execution-plan  azure-sql-database  cpu 

在我们的一个数据库中，我们有一个表，该表被多个线程密集并发访问。线程确实通过来更新或插入行MERGE。还有一些线程有时会删除行，因此表数据非常不稳定。进行upsert的线程有时会陷入死锁。该问题看起来类似于此问题中描述的问题。不过，不同之处在于，在我们的例子中，每个线程确实更新或插入一行。 简化的设置如下。该表是堆，上面有两个唯一的非聚集索引 CREATE TABLE [Cache] ( [UID] uniqueidentifier NOT NULL CONSTRAINT DF_Cache_UID DEFAULT (newid()), [ItemKey] varchar(200) NOT NULL, [FileName] nvarchar(255) NOT NULL, [Expires] datetime2(2) NOT NULL, CONSTRAINT [PK_Cache] PRIMARY KEY NONCLUSTERED ([UID]) ) GO CREATE UNIQUE INDEX IX_Cache ON [Cache] ([ItemKey]); GO 典型的查询是 DECLARE @itemKey varchar(200) = 'Item_0F3C43A6A6A14255B2EA977EA730EDF2', @fileName nvarchar(255) …

9 sql-server  execution-plan  deadlock  merge