Questions tagged «execution-plan»

我正在执行查询，产生计划： 统计IO： Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 'Workfile'. Scan count 128, logical reads 5952, physical reads 576, read-ahead reads 6080, lob logical reads 0, lob physical reads 0, …

21 sql-server  sql-server-2012  execution-plan 

说，我们有这样的查询： select a.*,b.* from a join b on a.col1=b.col1 and len(a.col1)=10 假设以上查询使用哈希联接并具有残差，则探测键为col1，残差为len(a.col1)=10。 但是，通过另一个示例，我可以看到探针和残差在同一列。以下是我要说的话的详细说明： 查询： select * from T1 join T2 on T1.a = T2.a 执行计划，突出显示探针和残差： 测试数据： create table T1 (a int, b int, x char(200)) create table T2 (a int, b int, x char(200)) set nocount on declare @i int …

21 sql-server  query-performance  execution-plan  database-internals 

SELECT此代码中的三个语句 USE [tempdb]; GO SET NOCOUNT ON; CREATE TABLE dbo.persist_test ( id INT NOT NULL , id5 AS (id * 5) , id5p AS (id * 5) PERSISTED ); INSERT INTO dbo.persist_test (id) VALUES (1), (2), (3); SELECT id FROM dbo.persist_test; SELECT id5 FROM dbo.persist_test; SELECT id5p FROM dbo.persist_test; DROP …

21 sql-server  sql-server-2008  execution-plan 

这是从注释到上一个问题的副产品： Postgres 9.4.4查询需要永远 使用PostgreSQL 9.4，Recheck Cond:在所输出的查询计划中的位图索引扫描之后，似乎总是出现一行EXPLAIN。 就像EXPLAIN所引用问题的输出中一样： -> Bitmap Heap Scan on table_three (cost=2446.92..19686.74 rows=8159 width=7) Recheck Cond: (("timestamp" > (now() - '30 days'::interval)) AND (client_id > 0)) -> BitmapAnd (cost=2446.92..2446.92 rows=8159 width=0) -> Bitmap Index Scan on table_one_timestamp_idx (cost=0.00..1040.00 rows=79941 width=0) Index Cond: ("timestamp" > (now() - '30 days'::interval)) …

21 postgresql  index  postgresql-9.4  execution-plan 

我有一个SQL Server 2012数据库。我注意到Reason for early termination of statement optimization某些查询的价值，而所有查询都给出Good Enough Plan Found。现在我的问题是： 什么是“提早终止语句优化的原因”的所有可能类型。我确实在msdn中进行了搜索，但没有完整的值列表。 是否有DMV或扩展事件列出了由于找到了“足够好的计划”以外的原因而终止优化的所有查询？我引用了以下两篇文章，其中未列出所有可能性。[此外，它们在我的数据库中给了我不同的结果]。 查找：查询编译超时 识别不够好的查询计划

20 sql-server  optimization  execution-plan 

SQL Server图形执行计划从右到左，从上到下阅读。产生的输出是否有意义SET STATISTICS IO ON？ 以下查询： SET STATISTICS IO ON; SELECT * FROM Sales.SalesOrderHeader AS soh JOIN Sales.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID JOIN Production.Product AS p ON sod.ProductID = p.ProductID; 生成此计划： 并STATISTICS IO输出： Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob …

20 sql-server  execution-plan 

此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 7年前。 我有一个带有“ TOP（X）”子句的SQL UPDATE语句，而我要更新值的行大约有40亿行。当我使用“ TOP（10）”时，我得到一个几乎立即执行的执行计划，但是当我使用“ TOP（50）”或更大时，查询永远不会完成（至少在我等待时）。它使用完全不同的执行计划。较小的查询使用一个非常简单的计划，该计划带有一对索引查找和一个嵌套循环联接，其中完全相同的查询（UPDATE语句的TOP子句中的行数不同）使用的方案涉及两个不同的索引查找，表假脱机，并行性以及其他一系列复杂性。 我已经使用“ OPTION（USE PLAN ...）”来强制它使用由较小查询生成的执行计划-当我这样做时，我可以在几秒钟内更新多达100,000行。我知道查询计划是好的，但是SQL Server仅在只涉及少量行的情况下才会自行选择该计划-更新中任何相当大的行数都会导致次优计划。 我以为应该归咎于并行性，所以我MAXDOP 1对查询进行设置，但是没有任何效果-这一步骤已经过去，但是糟糕的选择/性能却没有。我也sp_updatestats今天早上跑了，以确保不是这个原因。 我已经附上了两个执行计划-计划越短也越快。此外，这是有问题的查询（值得注意的是，无论行数是大还是小，我包含的SELECT似乎都是快速的）： update top (10000) FactSubscriberUsage3 set AccountID = sma.CustomerID --select top 50 f.AccountID, sma.CustomerID from FactSubscriberUsage3 f join dimTime t on f.TimeID = t.TimeID join #mac sma on f.macid = …

20 sql-server  query-performance  execution-plan 

我正在对性能不佳的存储过程的细节进行故障排除。该过程的这一部分将引发NO JOIN PREDICATE警告 select method = case methoddescription when 'blah' then 'Ethylene Oxide' when NULL then 'N/A' else methoddescription end, testmethod = case methoddescription when 'blah' then 'Biological Indicators' when NULL then 'N/A' else 'Dosimeter Reports' end, result = case when l.res is null or l.res <> 1 then 'Failed' …

20 sql-server  sql-server-2008-r2  execution-plan  warning 

碰到这个东西时，我正在研究其他东西。我正在生成包含一些数据的测试表，并运行不同的查询，以了解不同的写查询方式如何影响执行计划。这是我用来生成随机测试数据的脚本： IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID('t') AND type in (N'U')) DROP TABLE t GO CREATE TABLE t ( c1 int IDENTITY(1,1) NOT NULL ,c2 int NULL ) GO insert into t select top 1000000 a from (select t1.number*2048 + t2.number a, newid() b from [master]..spt_values …

20 sql-server  sql-server-2008-r2  execution-plan 

这可能属于观点类别，但我很好奇是否人们使用跟踪标志4199作为SQL Server的启动参数。对于那些使用过它的人，您在什么情况下遇到查询回归？ 当然，这似乎似乎是潜在的整体性能优势，我正在考虑在我们的非生产环境中在全球范围内启用它，并将其放置几个月以找出任何问题。 2014年（或2016年）默认情况下是否将4199中的修补程序纳入优化程序？尽管我理解不引入计划外更改的情况，但将所有这些修复隐藏在版本之间似乎很奇怪。 我们使用的是2008、2008R2，大部分使用的是2012。

19 sql-server  optimization  execution-plan 

给定以下堆表，该堆表具有从1到400编号的400行： DROP TABLE IF EXISTS dbo.N; GO SELECT SV.number INTO dbo.N FROM master.dbo.spt_values AS SV WHERE SV.[type] = N'P' AND SV.number BETWEEN 1 AND 400; 以及以下设置： SET NOCOUNT ON; SET STATISTICS IO, TIME OFF; SET STATISTICS XML OFF; SET TRANSACTION ISOLATION LEVEL READ COMMITTED; 以下SELECT语句将在6秒钟左右完成（demo，plan）： DECLARE @n integer = 400; …

18 sql-server  query-performance  execution-plan  insert 

产生“过度拨款”执行计划警告的条件是什么？ 查询内存授权检测到“ ExcessiveGrant”，这可能会影响可靠性。授予大小：初始5128 KB，最终5128 KB，已用16 KB。 短信服务 计划浏览器 Showplan XML <Warnings> <MemoryGrantWarning GrantWarningKind="Excessive Grant" RequestedMemory="5128" GrantedMemory="5128" MaxUsedMemory="16" /> </Warnings>

18 sql-server  execution-plan  warning  memory-grant 

我有一个典型的情况，参数嗅探会导致“不良”执行计划进入计划缓存，从而导致存储过程的后续执行非常缓慢。我可以使用局部变量OPTIMIZE FOR ... UNKNOWN和来“解决”此问题OPTION(RECOMPILE)。但是，我也可以深入查询并尝试对其进行优化。 我正在尝试确定是否应该：在有限的时间内解决问题，我想知道不这样做的代价。如我所见，如果我坚持使用OPTION(RECOMPILE)，最终结果是每次运行查询时都会重新创建查询计划。所以，我想我需要知道： 如何找出创建查询计划的成本是多少？ 为了回答我自己的问题，我已经使用Googled进行了查询（例如，使用该查询），并浏览了dm_exec_query_statsDMV列的文档 。我还检查了SSMS中的“实际查询计划”的输出窗口以查找此信息。最后，我已经搜查DBA.SE。这些都没有一个答案。 谁能告诉我？是否可以找到或衡量计划创建所需的时间？

18 sql-server  execution-plan 

create table T(ID int identity primary key) insert into T default values insert into T default values go select cast(ID as varchar(10)) as ID from T where ID = 1 上面的查询在查询计划中有一个警告。 <Warnings> <PlanAffectingConvert ConvertIssue="Cardinality Estimate" Expression="CONVERT(varchar(10),[xx].[dbo].[T].[ID],0)" /> </Warnings> 为什么会有警告？ 字段列表中的类型转换如何影响基数估计？

17 sql-server  sql-server-2012  execution-plan  type-conversion  cardinality-estimates 

为了回答SQL对分区的计数问题，Erik Darling发布了此代码来解决以下问题COUNT(DISTINCT) OVER ()： SELECT * FROM #MyTable AS mt CROSS APPLY ( SELECT COUNT(DISTINCT mt2.Col_B) AS dc FROM #MyTable AS mt2 WHERE mt2.Col_A = mt.Col_A -- GROUP BY mt2.Col_A ) AS ca; 查询使用CROSS APPLY（not OUTER APPLY），为什么执行计划中有外部联接而不是内部联接？ 同样，为什么取消注释group by子句会导致内部联接？ 我认为数据并不重要，但可以复制kevinwhat在另一个问题上给出的数据： create table #MyTable ( Col_A varchar(5), Col_B int ) insert …

17 sql-server  execution-plan  cross-apply