タグ付けされた質問 「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 

通常の列を永続的な計算列に変換すると、このクエリでインデックスシークを実行できなくなります。どうして？ 2016 SP1 CU1を含むいくつかのSQL Serverバージョンでテストされています。 レプロス 計算された列 通常の列 問題はtable1、col7です。 テーブルとクエリは、オリジナルの部分的な（そして簡略化された）バージョンです。クエリが別の方法で書き直される可能性があることは承知しており、何らかの理由で問題を回避しますが、コードに触れないようにする必要がありtable1ます。 ポールホワイトが示したように（ありがとう！）、シークは強制された場合に利用可能になるため、オプティマイザによってシークが選択されない理由と、シークを変更することなく、必要に応じてシークを実行するために別の方法を実行できるかどうかが問題になります。コード？ 問題のある部分を明確にするために、不良な実行計画の関連するスキャンを以下に示します。

9 sql-server  optimization  execution-plan 

インデックスまたはテーブルスキャンを使用する場合、SQL Serverは統計を使用してどちらが優れているかを確認します。 2,000万行のテーブルがあります。（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 

しばらく探してみたところ、答えが見つからなかったためこの質問を投稿し、似たような質問/回答があった場合は謝罪することにしました。 同じように設定された2つの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 Standard 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では、別のテーブルに結合するテーブル値関数があり、この「テーブル値関数」の行数をカウントする必要があります。実行プランを調べると、左側の結合テーブルが表示されています。どうして？左結合テーブルは、返される行数にどのように影響しますか？私は、dbエンジンが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が提供するクエリを使用すると、次のようになります。 EDIT2： アクティビティモニターを使用して、これを確認できます。 これは最も負荷の高いクエリです（最初のクエリは意図的なものであり、私たちはそれについて知っています）。 繰り返しますが、なぜこれselect * from...が理由なのかを知りたいのFETCH CURSORですが... EDIT3： この " select * from..."は別のサーバーから（経由でlinked server）実行されています。 さて、@ kinが言ったことを理解するのに問題があります。 これはexecution …

9 sql-server-2008  execution-plan  cursors  process 

この削除を実行すると： DELETE FROM ETLHeaders WHERE ETLHeaderID < 32465870 ... 39,157行を削除します。これは、クラスター化インデックスと主キーである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で、クエリプランにUDFを含めるには、SQL SentryでGet Estimated Planを実行する必要があることに気付きました。 「実際のプランを取得」を実行すると、論理読み取りやその他のメトリックにUDFで発生する操作が含まれているように見えません。このような場合、プロファイラーを使用する唯一の回避策はありますか？

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

いくつかのビューを持つスキーマがあります。実行プランをチェックして、適切なインデックスが配置され、使用されていることを確認する必要があります。 どうすればよいですか？ 私はむしろからの出力をコピー＆ペーストする必要はないだろうshow create view <viewname>にexplain景色の一部が他のビューの上に構築されている、特にとして、これは非常に苦痛になります。

9 mysql  performance  execution-plan  view 

ストアドプロシージャ内で実行するときに不適切なプランを使用する削除ステートメントがありますが、アドホックで実行するときにはるかに優れたプランを選択しています。 クエリで使用されるテーブルのすべてのインデックスを再構築し、すべてのキャッシュを削除しました。オプティマイザは引き続き、ストアドプロシージャに対して誤ったプランを選択します。 オプティマイザがストアドプロシージャとアドホックSQLで異なる実行プランを使用している理由を知りたいのですが。 更新：私はそれが結局のところパラメータだったに違いない-私がハードコードされた変数でアドホックコードを実行したとき、私は正しい値（それは日付であり、1年前の値です）で「悪い」計画を得ることができます「良い」計画を生み出すようです）。次に、クエリヒントを使用して、プロシージャに "適切な"プランを強制しようとします。 解決策：OPTIMIZE FOR UNKNOWNヒントを使用して、目的の計画を取得することになりました。

9 sql-server  execution-plan 

2つの非常によく似たクエリがあります 最初のクエリ： 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 2番目のクエリ： 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 Portalでパフォーマンス概要レポートを参照すると、データベースサーバーの負荷（DTU使用量）の大部分がCPUからのものであり、具体的には1つのクエリが原因であることがわかります。 ご覧のように、クエリ3780は、サーバーのほぼすべてのCPU使用率の原因です。 クエリ3780（下記参照）は基本的にアプリケーションの核心であり、ユーザーから頻繁に呼び出されるため、これは多少意味があります。また、必要な適切なデータセットを取得するために必要な多くの結合を伴う、かなり複雑なクエリでもあります。クエリは、次のようなsprocから取得されます。 -- @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 …

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

私たちのデータベースの1つに、複数のスレッドによって集中的に同時にアクセスされるテーブルがあります。スレッドはを介して行を更新または挿入しますMERGE。行を時々削除するスレッドもあるので、テーブルデータは非常に不安定です。アップサートを実行するスレッドは時々デッドロックに悩まされます。この問題は、この質問で説明されている問題に似ています。ただし、違いは、私たちの場合、各スレッドが1行だけを更新または挿入することです。 簡略化されたセットアップは次のとおりです。テーブルは、2つの一意の非クラスター化インデックスを持つヒープです。 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