Questions tagged «execution-plan»

我正在努力通过警告Operator usedtempdb 将查询计划上的排序操作的成本降至最低to spill data during execution with spill level 2 我发现有几个与泄漏级别为1的执行过程中的泄漏数据有关的帖子，但与级别2无关，而级别1似乎是由于过时的统计信息引起的，级别2呢？我找不到与关联的任何内容level 2。 我发现本文与排序警告有关非常有趣： 永不忽略SQL Server中的排序警告 我的SQL Server？ Microsoft SQL Server 2014（SP2）（KB3171021）-12.0.5000.0（X64）2016年6月17日19:14:09版权所有（c）Windows NT 6.3（Build 9600：）上的Microsoft Corporation Enterprise Edition（64位）（系统管理程序） 我的硬件？ 运行下面的查询以查找硬件： -来自SQL Server 2012的硬件信息 SELECT cpu_count AS [Logical CPU Count], hyperthread_ratio AS [Hyperthread Ratio], cpu_count/hyperthread_ratio AS [Physical CPU Count], physical_memory_kb/1024 AS …

17 sql-server  query-performance  memory  execution-plan  sort-operator 

在过去的5周中，大约每天的同一时间（清晨，可能取决于人们开始使用时的用户活动），每周一次，SQL Server 2016（AWS RDS，已镜像）开始超时查询。 所有表上的UPDATE STATISTICS始终会立即对其进行修复。 第一次之后，我让它每晚（而不是每周）更新所有表上的所有统计信息，但是仍然发生（更新统计信息运行后大约8小时，但并非每天运行）。 上一次，我启用了查询存储，以查看是否可以找到具体的查询/查询计划。我想我可以将其缩小到一个： 找到该查询后，我添加了一个推荐索引，该索引在此不常用的查询中丢失了（但它确实涉及很多常用表）。 错误的查询计划正在执行索引扫描（在只有1万行的表上）。不过，其他返回的查询计划（以毫秒为单位）也用于进行相同的扫描。创建新索引后，最新查询计划仅查找。但是，即使没有该索引，也有99％的时间在几毫秒内返回了索引，但是每周要花40秒以上的时间。 超时的坏消息：http : //brentozar.com/pastetheplan/?id=rymaWt56e 以前不会超时的计划：http : //brentozar.com/pastetheplan/?id=HyN7ftcpe 具有新索引的最新计划：http : //brentozar.com/pastetheplan/?id=ryLuGKcag 从2012年迁移到SQL Server 2016之后，这种情况开始发生。 DBCC CHECKDB不返回任何错误。 新索引会解决问题，使其不再选择错误的计划吗？ 我应该“强制”现在行之有效的计划吗？ 如何确保其他查询/计划不会发生这种情况？ 这是更大问题的征兆吗？ 我刚刚添加的索引： CREATE NONCLUSTERED INDEX idx_AppointmetnAttendee_AttendeeType ON [dbo].[AppointmentAttendee] ([UserID],[AttendeeType]) CREATE NONCLUSTERED INDEX [idx_appointment_start] ON [dbo].[Appointment] ( [ProjectID] ASC, [Start] ASC ) INCLUDE ( …

16 sql-server  execution-plan  sql-server-2016  statistics  query-store 

如何在执行计划中消除键查找（集群）运算符？ 表tblQuotes已经有一个聚集索引（QuoteID）和27个非聚集索引，因此我尝试不再创建任何索引。 我QuoteID在查询中放入了聚集索引列，希望对您有所帮助-但不幸的是还是一样。 执行计划在这里。 或查看它： 这就是“关键点查找”运算符所说的： 查询： declare @EffDateFrom datetime ='2017-02-01', @EffDateTo datetime ='2017-08-28' SET NOCOUNT ON SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED IF OBJECT_ID('tempdb..#Data') IS NOT NULL DROP TABLE #Data CREATE TABLE #Data ( QuoteID int NOT NULL, --clustered index [EffectiveDate] [datetime] NULL, --not indexed [Submitted] [int] NULL, [Quoted] …

16 sql-server  sql-server-2012  query-performance  execution-plan  bookmark-lookup 

线轴 在SQL Server中，有几种类型的线轴。我感兴趣的两个是Table Spool和Index spool，它们在修改查询之外。 只读查询（尤其是在嵌套循环联接的内侧）可以使用表或索引假脱机来潜在地减少I / O并提高查询性能。这些线轴可以是Eager或Lazy。就像你我一样。 我的问题是： 哪些因素影响表与索引假脱机的选择 哪些因素构成了热切线轴和惰性线轴之间的选择

15 sql-server  execution-plan 

如果使用“包含实际执行计划”运行查询，则该计划还将建议缺少的索引。索引详细信息MissingIndexes位于XML的内部标记中。计划中包含多个索引建议时会出现这种情况吗？我尝试了不同的sql查询，但是无法提供任何生成两个或多个缺失索引的查询。

15 sql-server  index  execution-plan 

我有一个SQL查询，过去两天我一直在尝试使用试错法和执行计划进行优化，但无济于事。请原谅我这样做，但我将在此处发布整个执行计划。我已尽力使查询和执行计划中的表名和列名通用化，以简化和保护我公司的IP。可以使用SQL Sentry Plan Explorer打开执行计划。 我已经做了相当多的T-SQL，但是使用执行计划来优化查询对我来说是一个新领域，并且我确实试图理解如何做到这一点。因此，如果有人可以帮助我并解释如何解释该执行计划以在查询中找到优化它的方法，我将永远感激不已。我还有许多要优化的查询-我只需要一个跳板就可以帮助我解决第一个问题。 这是查询： DECLARE @Param0 DATETIME = '2013-07-29'; DECLARE @Param1 INT = CONVERT(INT, CONVERT(VARCHAR, @Param0, 112)) DECLARE @Param2 VARCHAR(50) = 'ABC'; DECLARE @Param3 VARCHAR(100) = 'DEF'; DECLARE @Param4 VARCHAR(50) = 'XYZ'; DECLARE @Param5 VARCHAR(100) = NULL; DECLARE @Param6 VARCHAR(50) = 'Text3'; SET NOCOUNT ON DECLARE @MyTableVar TABLE …

15 sql-server  sql-server-2008  t-sql  optimization  execution-plan 

OFFSET ... FETCHSQL Server 2012引入的新模型提供了简单，快速的分页。考虑到两种形式在语义上是相同且非常普遍的，为什么根本没有区别？ 人们会假设优化器可以识别这两者，并（最大程度地）优化它们。 这是一个非常简单的情况，OFFSET ... FETCH根据成本估算，速度提高了约2倍。 SELECT * INTO #objects FROM sys.objects SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY object_id) r FROM #objects ) x WHERE r >= 30 AND r < (30 + 10) ORDER BY object_id SELECT * FROM #objects ORDER BY …

15 sql-server  sql-server-2012  execution-plan  optimization  offset-fetch 

表t有两个索引： create table t (a int, b int); create type int_pair as (a int, b int); create index t_row_idx on t (((a,b)::int_pair)); create index t_a_b_idx on t (a,b); insert into t (a,b) select i, i from generate_series(1, 100000) g(i) ; 没有索引与any运算符一起使用： explain analyze select * from t where (a,b) = …

15 postgresql  index  optimization  postgresql-9.4  execution-plan 

我刚刚在网站http://sqlfiddle.com上推出了一项功能，该功能使用户可以查看其查询的原始执行计划。对于PostgreSQL，MySQL和（在某种程度上）Oracle，可以理解原始执行计划的输出。但是，如果您查看SQL Server的执行计划输出（使用生成的SET SHOWPLAN_XML ON），那么即使对于相对简单的查询，也要经过大量的XML。这是一个示例（摘自该“小提琴”的上一个查询的执行计划：http : //sqlfiddle.com/#!3/ 1fa93/1）： <ShowPlanXML xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan" Version="1.1" Build="10.50.2500.0"> <BatchSequence> <Batch> <Statements> <StmtSimple StatementText="
select * from supportContacts" StatementId="1" StatementCompId="1" StatementType="SELECT" StatementSubTreeCost="0.0032853" StatementEstRows="3" StatementOptmLevel="TRIVIAL" QueryHash="0x498D13A3874D9B6E" QueryPlanHash="0xD5DDBD3C2D195E96"> <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="false" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false"/> <QueryPlan CachedPlanSize="16" CompileTime="0" CompileCPU="0" CompileMemory="72"> <RelOp NodeId="0" PhysicalOp="Clustered Index Scan" LogicalOp="Clustered Index Scan" EstimateRows="3" EstimateIO="0.003125" …

15 sql-server  sql-server-2008-r2  execution-plan 

我有一张几十行的桌子。简化的设置如下 CREATE TABLE #data ([Id] int, [Status] int); INSERT INTO #data VALUES (100, 1), (101, 2), (102, 3), (103, 2); 我有一个查询，可以将该表连接到一组表值构造的行（由变量和常量组成）上，例如 DECLARE @id1 int = 101, @id2 int = 105; SELECT COALESCE(p.[Code], 'X') AS [Code], COALESCE(d.[Status], 0) AS [Status] FROM (VALUES (@id1, 'A'), (@id2, 'B') ) p([Id], [Code]) FULL JOIN …

14 sql-server  execution-plan 

给定下表，唯一聚集索引和统计信息： CREATE TABLE dbo.Banana ( pk integer NOT NULL, c1 char(1) NOT NULL, c2 char(1) NOT NULL ); CREATE UNIQUE CLUSTERED INDEX pk ON dbo.Banana (pk); CREATE STATISTICS c1 ON dbo.Banana (c1); CREATE STATISTICS c2 ON dbo.Banana (c2); INSERT dbo.Banana (pk, c1, c2) VALUES (1, 'A', 'W'), (2, 'B', 'X'), …

14 sql-server  update  execution-plan  statistics  unique-constraint 

我遇到了开发人员代码，其中在执行SQL查询之前广泛使用了SqlCommand.Prepare（）（请参见MSDN）方法。我想知道这样做的好处是什么？ 样品： command.Prepare(); command.ExecuteNonQuery(); //... command.Parameters[0].Value = 20; command.ExecuteNonQuery(); 我玩了一些，并进行了追踪。调用Prepare()方法后，Command的执行使Sql Server执行以下语句： declare @p1 int set @p1=1 exec sp_prepexec @p1 output,N'@id int,@desc text',N'INSERT INTO dbo.testtable (id) VALUES (@id)',@id=20' select @p1 之后，当获取参数的值并SqlCommand.ExecuteNonQuery()调用该参数时，将在Sql-Server上执行以下操作： exec sp_execute 1,@id=20 对我来说，这看起来像该语句在Prepare()执行后立即得到了编译。我想知道这样做有什么好处？这是否意味着将其放入计划缓存中，并且可以在使用所需参数值执行最终查询后立即重新使用它？ 我发现（并记录在另一个问题中）用SqlParameters执行的SqlCommands总是包装在sp_executesql过程调用中。这使Sql Server能够独立于参数值存储和重用计划。 关于这一点，我想知道该prepare()方法是无用的还是过时的，或者我是否在这里遗漏了什么？

14 sql-server  sql-server-2008-r2  execution-plan  prepared-statement  plan-cache 

我们的生产环境中存在这个问题。 Windows NT 6.1（内部版本7601：Service Pack 1）上的Microsoft SQL Server 2008 R2（SP1）-10.50.2500.0（X64）-企业版（64位）。 SQL Server将删除所有（几乎100％）旧的执行计划，并每天隔夜（从11:00 PM到8:00 AM）重新创建它们。当“自动更新统计信息”处于禁用状态时，甚至会发生这种情况。我们已在过去2-3周内启用了“自动更新统计信息”。但它仍在发生。 我们真的不知道是什么触发了计划的重新生成，但是我们确信我们不会手动进行。 与重新生成计划的时间真正吻合的唯一一件事是我们拥有的DB​​维护工作：每日索引重组（当碎片为5-30％时）和每日索引重建（当碎片大于30％时） ）的工作。通常，此日常维护工作仅会进行重组（因为索引碎片每天都不会超过30％）。 影响： 这些新创建的计划使一些UDF调用/查询调用（从UI /网页调用）花费的时间更长（几分钟而不是不到1秒），因此会话堆积如山，使CPU接近90％ 。 当这些卡住的会话被强制删除（在DB端）时，问题消失了； 1）当手动清除了所有相应的执行计划（对于查询）时，或者2）当UDF改变了（对于功能）时，问题就消失了。从那时起，SQL Server创建的任何新计划都可以在一整天内完美运行，直到第二天早上出现相同问题为止。同样，这种行为也不是100％一致的，我们并不是每天早上都真正看到它。但是，在一段时间内，我们连续4-5天一直在观察它。 问题似乎发生在工作时间早晨，即在更密集地访问UI /网页时。 有谁知道这是什么原因以及如何解决这个问题的线索？任何帮助将非常感激。

14 sql-server  sql-server-2008  execution-plan  statistics 

我知道出于性能原因应避免使用它，但是我正在尝试展示一种情况，以使其演示如何确保不出现。 但是，我最后遇到了索引丢失警告，但是优化器选择不创建临时索引。 我正在使用的查询是 SELECT z.a FROM dbo.t5 AS z WITH(INDEX(0)) WHERE EXISTS ( SELECT y.a FROM dbo.t4 AS y WHERE y.a = z.a ) OPTION (MAXDOP 1); 表模式为： CREATE TABLE dbo.t4 ( a integer NULL, b varchar(1000) NULL, p varchar(100) NULL ); CREATE TABLE dbo.t5 ( a integer NULL, b …

14 sql-server-2012  t-sql  execution-plan  index-spool 

如果计划是针对可用性组中的主数据库执行的，则该计划是否适用于在辅助数据库上运行的查询？ 我正在寻找涵盖计划强制的两种可能性的答案： 计划指南 查询存储强制计划 我阅读了以下内容，这些内容表明QS强制计划不会继续存在，但找不到文档中的权威内容或有关计划指南的任何内容。 Erin Stellato的查询存储和可用性组 在 Vikas Rana的AlwaysOn可读辅助数据库上查询数据存储强制计划行为 强迫的结论性证据将是二级执行计划中存在Use Plan或PlanGuideName和PlanGuideDB属性。

14 sql-server  availability-groups  execution-plan  query-store  plan-guides