タグ付けされた質問 「cardinality-estimates」

SQL Server 2012では800ミリ秒で実行され、SQL Server 2014では約170秒かかるクエリがあります。これを、Row Count Spool演算子のカーディナリティーの見積もりが悪いものに絞り込んだと思います。スプールオペレーターについて少し読んだことがありますが（例：こことここ）、まだいくつかのことを理解できません。 このクエリにRow Count Spool演算子が必要なのはなぜですか？正確さのために必要だとは思わないので、具体的にどのような最適化を提供しようとしているのですか？ SQL ServerがRow Count Spool演算子への結合がすべての行を削除すると推定するのはなぜですか？ これはSQL Server 2014のバグですか？もしそうなら、私はConnectにファイルします。しかし、私は最初により深い理解をお願いします。 注：LEFT JOINSQL Server 2012とSQL Server 2014の両方で許容可能なパフォーマンスを実現するために、クエリをとして書き換えるか、テーブルにインデックスを追加できます。この質問は、この特定のクエリを理解し、詳細に計画することに関するもので、詳細については説明しません。クエリの言い方を変えるには 遅いクエリ 完全なテストスクリプトについては、このPastebinを参照してください。これが私が見ている特定のテストクエリです： -- Prune any existing customers from the set of potential new customers -- This query is much slower than expected in SQL Server 2014 SELECT …

12 sql-server  query-performance  sql-server-2014  cardinality-estimates 

一部の重複を削除しようとする特定のクリーンアップコードがあります。 これは多くの顧客サイトで完全に実行されます。ログから、このクエリでは少なくとも1秒から45秒が消費されていることがわかります。 DELETE FROM [tbl] WHERE [Id] NOT IN ( SELECT MIN([Id]) FROM [tbl] GROUP BY [IdProject], [IdRepresentative], [TimeStart] ) しかし、私はこのクエリを4時間以上（現在までで、終了しない）実行している顧客がいます！私はDBをチェックしました（DBCC CHECKDB）、統計情報を更新しました（sp_updatestats）もUPDATE STATISTICS [tbl] WITH FULLSCAN変更を示していません。 お客様からDBの元のバックアップがあります。SQL Server 14.0.2002.14で実行しています。Standard Editionを持っていますが、お客様はExpress Editionを使用しています。 他の誰もDBを使用していないことをアクティビティモニターで確認できます。待機時間はなく、CPUは25％使用されています（4つのCPUのうちの1つのみ）。また、この私のテストケースでは、他の誰もDBを使用していません。 私はクエリを再構成し、このステートメントをチェックしました： DELETE FROM [tbl] FROM [tbl] AS t LEFT OUTER JOIN ( SELECT MIN([Id]) AS [IdMin] FROM [tbl] …

11 sql-server  query-performance  execution-plan  sql-server-2017  cardinality-estimates 

実際の実行プランでプラン表示分析（SSMS）を使用して、パフォーマンスの遅いクエリをトラブルシューティングしようとしています。分析ツールは、行数の見積もりが計画のいくつかの場所で返された結果からずれていることを指摘し、さらにいくつかの暗黙の変換警告を与えます。 これらのintからVarcharへの暗黙的な変換を理解できません-参照されるフィールドはクエリのパラメーター/フィルターの一部ではなく、関係するすべてのテーブルで列のデータ型は同じです： 以下のCardinalityEstimate警告が表示されます。 式の型変換（CONVERT_IMPLICIT（varchar（12）、[ccd]。[profileid]、0））は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、私のDB内のすべての整数です 式の型変換（CONVERT_IMPLICIT（varchar（6）、[ccd]。[nodeid]、0））は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、私のDBのあらゆる場所でsmallintです 式の型変換（CONVERT_IMPLICIT（varchar（6）、[ccd]。[sessionseqnum]、0））は、クエリプランの選択で "CardinalityEstimate"に影響を与える可能性があります-このフィールドは、DB内のあらゆる場所で小さな整数です 式の型変換（CONVERT_IMPLICIT（varchar（41）、[ccd]。[sessionid]、0））は、クエリプランの選択で "CardinalityEstimate"に影響する可能性があります-このフィールドは、DBのすべての場所で10進数です [編集]参照用のクエリと実際の実行計画は次の とおりですhttps://www.brentozar.com/pastetheplan/?id=SysYt0NzN そして、テーブルの定義。 /****** Object: Table [dbo].[agentconnectiondetail] Script Date: 1/10/2019 9:10:04 AM ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE TABLE [dbo].[agentconnectiondetail]( [sessionid] [decimal](18, 0) NOT NULL, [sessionseqnum] [smallint] NOT NULL, [nodeid] [smallint] NOT NULL, [profileid] [int] …

11 sql-server  execution-plan  sql-server-2017  type-conversion  cardinality-estimates 

32 GBのサーバーでは、最大メモリが25 GBのSQL Server 2014 SP2を実行しており、2つのテーブルがあります。ここでは、両方のテーブルの構造が簡略化されています。 CREATE TABLE [dbo].[Settings]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceId] [int] NULL, [typeID] [int] NULL, [remark] [varchar](max) NULL, CONSTRAINT [PK_Settings] PRIMARY KEY CLUSTERED ([id] ASC) ) ON [PRIMARY] GO CREATE TABLE [dbo].[Resources]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceUID] [int] NULL, CONSTRAINT [PK_Resources] PRIMARY KEY CLUSTERED …

10 sql-server  query-performance  tempdb  cardinality-estimates 

パーティションビューに履歴データを格納するアーカイブデータベースを維持しています。パーティション化列は日時です。ビューの下の各テーブルには、1か月分のデータが格納されます。 各テーブルのイベントを、datetime列のチェック制約で制約します。これにより、オプティマイザは、イベント日時列でフィルタするクエリを検索するテーブルを制限できます。 チェック制約の名前はSQL Serverによって生成されているため、名前を確認しても何を行うかを知るのは困難です。 制約名を「CK_TableName_Partition」の形式にしたい。 このクエリを使用し、sql_text列からデータをコピーして、名前変更スクリプトを生成できます。WHERE句は、SQL Serverによって生成されたように見える名前のチェック制約に一致します。 SELECT checks.name AS check_name, tabs.name AS table_name, skemas.name AS schema_name, cols.name AS column_name, N' EXECUTE sys.sp_rename @objname = N''' + skemas.name + N'.' + checks.name + N''', @newname = N''CK_' + tabs.name + N'_Partition'', @objtype = ''OBJECT'';' AS sql_text FROM sys.check_constraints AS checks …

10 sql-server  optimization  cardinality-estimates 

マスターテーブルを詳細テーブルに結合するときに、SQL Server 2014が大きい（詳細）テーブルの基数推定を結合出力の基数推定として使用するようにするにはどうすればよいですか？ たとえば、10Kのマスター行を100Kの詳細行に結合する場合、SQL Serverで結合を100K行で推定します-詳細行の推定数と同じです。すべての詳細行に常に対応するマスター行があるという事実をSQL Serverの推定器が活用できるようにするには、クエリやテーブル、インデックス、あるいはその両方をどのように構成すればよいですか？（それらの間の結合は、カーディナリティの推定値を決して減らすべきではないという意味です。） 詳細はこちらです。このデータベースには、マスター/詳細のテーブルのペアがありVisitTargetます。販売トランザクションごとに1つの行があり、トランザクションVisitSaleごとに製品ごとに1つの行があります。これは1対多の関係です。VisitTargetの行が1つで、平均で10件のVisitSale行があります。 テーブルは次のようになります（この質問に関連する列のみを簡略化しています）。 -- "master" table CREATE TABLE VisitTarget ( VisitTargetId int IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, SaleDate date NOT NULL, StoreId int NOT NULL -- other columns omitted for clarity ); -- covering index for date-scoped queries CREATE NONCLUSTERED INDEX IX_VisitTarget_SaleDate ON VisitTarget …

9 sql-server  sql-server-2014  execution-plan  cardinality-estimates 

1組の列（両方int）で結合する3つの「大きな」テーブルがあります。 Table1には2億行まで Table2には約150万行あります Table3には約600万行あります 各テーブルには、上のクラスタ化インデックスを持っているKey1、Key2して、1つの以上の列。Key1カーディナリティが低く、非常にゆがんでいます。これは常にWHERE句で参照されます。条項でKey2言及されていないWHERE。各結合は多対多です。 問題は、カーディナリティの推定にあります。各結合の出力見積もりは、大きくなるのではなく小さくなります。これにより、実際の結果が数百万に相当する場合、最終的な推定値は数百になります。 CEを手掛かりにしてより良い推定を行う方法はありますか？ SELECT 1 FROM Table1 t1 JOIN Table2 t2 ON t1.Key1 = t2.Key1 AND t1.Key2 = t2.Key2 JOIN Table3 t3 ON t1.Key1 = t3.Key1 AND t1.Key2 = t3.Key2 WHERE t1.Key1 = 1; 私が試したソリューション： 上の複数列の統計情報を作成しKey1、Key2 大量のフィルターされた統計を作成するKey1（これはかなり役に立ちますが、ユーザーが作成した何千もの統計がデータベースに残ることになります。） マスクされた実行計画（悪いマスキングのため申し訳ありません） 私が見ている場合、結果には900万行があります。新しいCEは180行を推定します。従来のCEでは6100行と推定されています。 これは再現可能な例です： DROP TABLE IF EXISTS #Table1, #Table2, …

9 sql-server  join  sql-server-2016  many-to-many  cardinality-estimates 

SQL ServerがSQL Server 2014のwhere句の「より大きい」と「等しい」をどのように推定するかを理解しようとしています。 私がそうすれば、それがステップに到達したときのカーディナリティ推定は理解していると思います select * from charge where charge_dt >= '1999-10-13 10:47:38.550' カーディナリティの推定値は6672で、32（EQ_ROWS）+ 6624（RANGE_ROWS）+ 16（EQ_ROWS）= 6672（下のスクリーンショットのヒストグラム）として簡単に計算できます。 しかし、私がするとき select * from charge where charge_dt >= '1999-10-13 10:48:38.550' （時間を10:48に増やしたため、ステップではありません） 推定値は4844.13です。 それはどのように計算されますか？

9 sql-server  sql-server-2014  performance-tuning  cardinality-estimates