タグ付けされた質問 「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このコードの3つのステートメント 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でこれを検索しましたが、値の完全なリストを取得できませんでした。 Good Enough Plan Found以外の理由で最適化が終了したすべてのクエリをリストするDMVまたは拡張イベントはありますか？可能性の完全なリストを掲載していない次の2つの記事を参照しました。[また、私のデータベースでは異なる結果が得られます]。 検出：クエリコンパイルタイムアウト 十分ではないクエリプランの特定

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 Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 「TOP（X）」句を含むSQL UPDATEステートメントがあり、値を更新する行には約40億行あります。「TOP（10）」を使用すると、ほぼ瞬時に実行される1つの実行プランが得られますが、「TOP（50）」以上を使用すると、クエリは（少なくとも、待機中ではなく）終了しません。まったく異なる実行計画を使用します。小さいクエリは、インデックスシークとネストされたループ結合のペアを持つ非常に単純なプランを使用します。まったく同じクエリ（UPDATEステートメントのTOP句の行数が異なる）は、2つの異なるインデックスシークを含むプランを使用します、テーブルスプール、並列処理、その他多数の複雑さ。 「OPTION（USE PLAN ...）」を使用して、より小さいクエリによって生成された実行プランを強制的に使用しました。これを行うと、数秒で100,000行も更新できます。クエリプランが良好であることはわかっていますが、SQL Serverは少数の行のみが関係している場合にのみそのプランを選択します。更新でかなり多くの行数があると、最適ではないプランになります。 並列処理のせいかもしれないと思ったのでMAXDOP 1、クエリを設定しましたが、効果はありません-そのステップはなくなりましたが、選択/パフォーマンスの低下はありません。sp_updatestatsそれが原因ではないことを確認するために、今朝も走りました。 2つの実行計画を添付しました-短いものは速いものです。さらに、問題のクエリは次のとおりです（含まれている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 = sma.macid and t.TimeValue between sma.StartDate and sma.enddate …

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 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 このことに出会ったとき、私は他の何かを研究していました。いくつかのデータを含むテストテーブルを生成し、さまざまなクエリを実行して、クエリを記述するさまざまな方法が実行プランにどのように影響するかを調べていました。ランダムテストデータの生成に使用したスクリプトは次のとおりです。 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 …

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

これは意見の範疇に入るかもしれませんが、人々がSQL Serverの起動パラメーターとしてトレースフラグ4199を使用している場合、私は興味があります。それを使用した人のために、どのような状況でクエリ回帰が発生しましたか？ 確かに全体的なパフォーマンスの向上の可能性があるように思えます。非実稼働環境でグローバルに有効にし、問題を排除するために数か月間放置することを検討しています。 4199の修正は、2014年（または2016年）にデフォルトでオプティマイザーに反映されますか？予期しない計画変更を導入しない場合は理解できますが、バージョン間でこれらの修正をすべて隠しておくのは奇妙に思えます。 2008、2008R2、主に2012を使用しています。

19 sql-server  optimization  execution-plan 

「過剰付与」実行計画の警告を生成する条件は何ですか？ クエリメモリ許可が「ExcessiveGrant」を検出しました。これは信頼性に影響を与える可能性があります。許可サイズ：初期5128 KB、最終5128 KB、使用済み16 KB。 SSMS 計画エクスプローラー Showplan XML <Warnings> <MemoryGrantWarning GrantWarningKind="Excessive Grant" RequestedMemory="5128" GrantedMemory="5128" MaxUsedMemory="16" /> </Warnings>

18 sql-server  execution-plan  warning  memory-grant 

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 

パラメータスニッフィングにより、「悪い」実行プランがプランキャッシュに到達し、その後のストアドプロシージャの実行が非常に遅くなる典型的なケースがあります。ローカル変数でこの問題を「解決」できますが、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（ないOUTER APPLY）、なぜそこにある外側は代わりの実行計画に参加し、内側が参加？ また、group by句のコメントを外すと内部結合が発生するのはなぜですか？ データは重要ではないと思いますが、他の質問のkevinwhatによって与えられたデータからコピーします。 create table #MyTable ( Col_A varchar(5), Col_B int ) insert into …

17 sql-server  execution-plan  cross-apply