タグ付けされた質問 「execution-plan」

クエリを処理するためにクエリオプティマイザーによって選択された戦略。

1
PostgreSQLがより高価な結合順序を選択するのはなぜですか？
デフォルトを使用したPostgreSQL、および default_statistics_target=1000 random_page_cost=1.5 バージョン PostgreSQL 10.4 on x86_64-pc-linux-musl, compiled by gcc (Alpine 6.4.0) 6.4.0, 64-bit 掃除機をかけて分析しました。クエリは非常に簡単です。 SELECT r.price FROM account_payer ap JOIN account_contract ac ON ap.id = ac.account_payer_id JOIN account_schedule "as" ON ac.id = "as".account_contract_id JOIN schedule s ON "as".id = s.account_schedule_id JOIN rate r ON s.id = r.schedule_id WHERE …
3
このクエリの結果の列をすべて選択するのは、関心のある1つの列を選択するより速いのはなぜですか
を使用するselect *と、読み取りがはるかに少ないだけでなく、使用するよりも大幅に少ないCPU時間を使用するクエリがありますselect c.Foo。 これはクエリです： select top 1000 c.ID from ATable a join BTable b on b.OrderKey = a.OrderKey and b.ClientId = a.ClientId join CTable c on c.OrderId = b.OrderId and c.ShipKey = a.ShipKey where (a.NextAnalysisDate is null or a.NextAnalysisDate < @dateCutOff) and b.IsVoided = 0 and c.ComplianceStatus in (3, 5) …
1
なぜこのLEFT JOINがLEFT JOIN LATERALよりもパフォーマンスがそれほど悪いのですか？
次の表があります（Sakilaデータベースから取得）。 film：film_idはpkeyです 俳優：actor_idはpkeyです film_actor：film_idとactor_idは、映画/俳優のfkeyです 特定の映画を選択しています。この映画では、すべての俳優がその映画に参加することも望んでいます。これには2つのクエリがあります。1つのクエリLEFT JOINと1 つのクエリですLEFT JOIN LATERAL。 select film.film_id, film.title, a.actors from film left join ( select film_actor.film_id, array_agg(first_name) as actors from actor inner join film_actor using(actor_id) group by film_actor.film_id ) as a on a.film_id = film.film_id where film.title = 'ACADEMY DINOSAUR' order by film.title; select film.film_id, film.title, …
1
SQL Serverでの実行計画の作成はどの程度決定的ですか？
次の定数がある場合： 同じ構造（テーブル、インデックスなど）を持つ同じデータベース 同じデータ 同じSQL Serverとハードウェア構成 同じ統計 クライアントの同じSETオプション 同じSQL Serverバージョン 同じトレースフラグ これらの定数を指定すると、SQL Serverは特定のクエリに対して常に同じプランを生成しますか？ そうでない場合、他の考慮事項はありますか？考慮すべき非決定性の要素もありますか？
2
sp_executesqlはクエリプランをいつ更新しますか？
私はDBAではないので、私の素朴さを許さなければなりませんが、データベースの変更とストアドプロシージャの統計を時間の経過とともに再コンパイルして、クエリプランを最新の統計で最新に保つ必要があることを理解しています。 私が最新の統計に対して再コンパイルされた私のデータベース内のストアドプロシージャ持つと仮定すると、いくつかのコードでストアドプロシージャをインライニングとそれを包むの意味するものは、一定の間隔をsp_executesql文では？プロシージャの再コンパイルの一部として行われていたクエリプランの更新が失われますか？ この変更を行う前に考慮する必要のあるもの（権限以外）があれば、あなたの洞察に感謝します。 私はMSDNでこれを読みました： SQL Serverクエリオプティマイザーが既存の実行プランと新しいTransact-SQL文字列を一致させる機能は、特に複雑なTransact-SQLステートメントで、文字列のテキストのパラメーター値が絶えず変化することによって妨げられます。 だから、私がインラインしてラップしようとしているストアドプロシージャにsp_executesql実際にいくつかのパラメータが含まれていると仮定すると、これは私の実行計画がキャッシュされているが、SQL Serverがそれを見つけて再利用することをより難しくしているということですか？
1
SQL Server 2008は実行計画の作成日を保存しますか？
最近、使用するアプリケーションをアップグレードしました。これには、データベースのスキーマの変更が含まれていました。これらの変更により、キャッシュされた実行計画が強制的に破棄される可能性がありました。SQL Serverが多数の新しいプランを作成することを余儀なくされた場合、これによりユーザーエクスペリエンスが低下する可能性がありました。これが事実かどうかを知りたい。 それで、私の質問は、SQL Server 2008はキャッシュされた実行プランの作成日を保存するのですか？管理ビューにsys.dm_exec_cached_plansは日付フィールドがないため、そうではないと思われます。
5
SentryOne Plan Explorerは動作しますか？
SentryOne Plan Explorerは広告どおりに機能しますか？それは合法ですか？気をつけるべきことや心配することはありますか？ SSMSの悪夢のような実行計画の見方と比較して、ホットパスを色で示しているように見えます。 私の懸念は-悪意のあるデータやその他のデータを変更しますか？ 編集：私はそれについて聞いたばかりで、会社について聞いたことがありません。
1
where句が `value（）`でフィルタリングするときにセカンダリ選択インデックスが使用されないのはなぜですか？
セットアップ： create table dbo.T ( ID int identity primary key, XMLDoc xml not null ); insert into dbo.T(XMLDoc) select ( select N.Number for xml path(''), type ) from ( select top(10000) row_number() over(order by (select null)) as Number from sys.columns as c1, sys.columns as c2 ) as N; 各行のサンプルXML： <Number>314</Number> …
1
SQL Serverのオプティマイザーは、結合されたテーブルの行数をどのように推定しますか？
AdventureWorks2012データベースでこのクエリを実行しています。 SELECT s.SalesOrderID, d.CarrierTrackingNumber, d.ProductID, d.OrderQty FROM Sales.SalesOrderHeader s JOIN Sales.SalesOrderDetail d ON s.SalesOrderID = d.SalesOrderID WHERE s.CustomerID = 11077 推定実行計画を見ると、次のことがわかります。 最初のインデックスシーク（右上）はIX_SalesOrderHeader_CustomerIDインデックスを使用し、リテラル11077で検索しています。推定推定値は2.6192行です。 を使用するDBCC SHOW_STATISTICS ('Sales.SalesOrderHeader', 'IX_SalesOrderHeader_CustomerID') WITH HISTOGRAMと、値11077が2つのサンプリングされたキー11019と11091の間にあることがわかります。 11019から11091までの個別の行の平均数は2.619718であり、2.61972に丸められます。これは、インデックスシークで表示される推定行の値です。 私が理解していない部分は、SalesOrderDetailテーブルに対するクラスター化インデックスシークの推定行数です。 私が実行した場合DBCC SHOW_STATISTICS ('Sales.SalesOrderDetail', 'PK_SalesOrderDetail_SalesOrderID_SalesOrderDetailID')： したがって、SalesOrderID（私が参加している）の密度は3.178134E-05です。これは、1 / 3.178134E-05（31465）がSalesOrderDetailテーブルの一意のSalesOrderID値の数に等しいことを意味します。 SalesOrderDetailに31465個の一意のSalesOrderIDがあり、均等に分布している場合、SalesOrderIDあたりの平均行数は121317（行の総数）を31465で割った値です。平均は3.85561です。 したがって、ループスルーの推定行数が2.61972で、平均が3.85561で返される場合、推定行数は2.61972 * 3.85561 = 10.10062になると思います。 ただし、推定行数は11.4867です。 2番目の推定値の私の理解は間違っていると思います。異なる数字はそれを示しているようです。私は何が欠けていますか？
3
並列処理（パーティションストリーム）演算子が行の推定値を1に減らすのはなぜですか？
SQL Server 2012 Enterpriseを使用しています。私は完全に直感的ではないいくつかの動作を示しているSQLプランに出会いました。大量のパラレルインデックススキャン操作の後、パラレル化（パーティションストリーム）操作が発生しますが、インデックススキャン（Object10.Index2）によって返される行の推定値を強制終了し、推定値を1に減らします。この振る舞いを説明するものに出会ったことはありません。クエリは非常に単純ですが、各テーブルには数百万のレコードが含まれています。これはDWHロードプロセスの一部であり、この中間データセットは何度も触れられますが、私が抱えている問題は、特に行の見積もりに関連しています。正確な行の推定値が並列処理（パーティション分割）演算子内で1になる理由を説明できますか？また、 計画を貼り付けるために完全な計画を投稿しました。 問題の操作は次のとおりです。 コンテキストを追加する場合に備えてプランツリーを含める： Paul Whiteが提出したこのConnectアイテムのバリエーションにぶつかることはありますか（彼のブログでさらに詳しく説明しています）。少なくとも、私が見つけた唯一のものは、プレイ中のTOP演算子がなくても、私が実行しているものに少しでも近いようです。
2
WHERE句が「含まれる」列の恩恵を受けるのはなぜですか？
この回答によれば、制限に使用される列にインデックスが構築されない限り、クエリはインデックスの恩恵を受けません。 私にはこの定義があります： CREATE TABLE [dbo].[JobItems] ( [ItemId] UNIQUEIDENTIFIER NOT NULL, [ItemState] INT NOT NULL, [ItemPriority] INT NOT NULL, [CreationTime] DATETIME NULL DEFAULT GETUTCDATE(), [LastAccessTime] DATETIME NULL DEFAULT GETUTCDATE(), -- other columns ); CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex] ON [dbo].[JobItems]([ItemId] ASC); GO CREATE INDEX [GetItemToProcessIndex] ON [dbo].[JobItems]([ItemState], [ItemPriority], [CreationTime]) INCLUDE (LastAccessTime); …
5
Azure SQL Databaseから不適切な実行プランを削除するにはどうすればよいですか？
DBCC FREEPROCCACHEAzure SQL DBでは機能しません。どうすれば、実稼働システムを傷つけないように計画を強制的にキャッシュから追い出すことができますか（つまり、テーブルを自由に変更することはできません）。これは特にEntity Frameworkによって作成されたSQL向けであるため、これらは自己管理型のストアドプロシージャではありません。事実上動的なSQLです。 （ソースは悪いインデックス->悪い統計などでした。それはすべて修正されましたが、悪い計画は消えません。） 更新： 彼が最初に到着したとき、@ mrdennyのソリューションを選択しました。ただし、@ Aaron Bertrandのスクリプトを使用して作業を正常に実行しています。みんな助けてくれてありがとう!!
3
連結物理操作：実行の順序を保証しますか？
標準SQLでは、aの結果のunion all順序は保証されていません。だから、次のようなもの： select 'A' as c union all select 'B' 任意の順序で2つの行を返すことができます（ただし、実際に知っているデータベースでは、「A」が「B」よりも前になります）。 SQL Serverでは、これは「連結」物理操作を使用した実行計画になります。 連結操作が入力をスキャンし、使用可能なレコードがある入力をすべて返すと簡単に想像できます。しかし、私はウェブ上で次の文を見つけました（ここ）： クエリプロセッサは、計画に演算子が表示される順序でこの計画を実行します。最初の計画が一番上で、最後の計画が最後です。 質問：これは実際には本当ですか？これは真実であることが保証されていますか？ Microsoftのドキュメントには、入力が最初から最後まで順番にスキャンされるという参照は見つかりませんでした。一方、実行しようとすると、結果は、入力が実際に順番に処理されていることを示唆しています。 エンジンが一度に複数の入力を処理する方法はありますか？私のテスト（定数よりもはるかに複雑な式を使用）は、並列対応の8コアマシン上で実行され、ほとんどのクエリは並列処理を利用しています。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.