データベース管理者 query-optimization

2

最近この問題に遭遇しましたが、オンラインで議論することができませんでした。以下のクエリ DECLARE @S VARCHAR(1) = ''; WITH T AS (SELECT name + @S AS name2, * FROM master..spt_values) SELECT * FROM T T1 INNER JOIN T T2 ON T1.name2 = T2.name2; ネストされたループ計画を常に取得します問題INNER HASH JOINまたはINNER MERGE JOINヒントで問題を強制しようとすると、次のエラーが生成されます。このクエリで定義されたヒントのため、クエリプロセッサはクエリプランを作成できませんでした。ヒントを指定せずに、SET FORCEPLANを使用せずに、クエリを再送信します。ハッシュ結合またはマージ結合の使用を許可する回避策を見つけました-変数を集約にラップします。生成された計画は大幅に低コストです（19.2025対0.261987） DECLARE @S2 VARCHAR(1) = ''; WITH T AS (SELECT …

16 sql-server performance query-optimization

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番目の推定値の私の理解は間違っていると思います。異なる数字はそれを示しているようです。私は何が欠けていますか？

13 sql-server sql-server-2012 query-optimization execution-plan cardinality-estimates

1

このクエリで主（クラスター）キーが使用されないのはなぜですか？

スキーマ構造が次のようなSQL Server 2008 R2テーブルがあります。 CREATE TABLE [dbo].[CDSIM_BE] ( [ID] [bigint] NOT NULL, [EquipmentID] [varchar](50) NOT NULL, [SerialNumber] [varchar](50) NULL, [PyrID] [varchar](50) NULL, [MeasMode] [varchar](50) NULL, [ReadTime] [datetime] NOT NULL, [SubID] [varchar](15) NULL, [ProbePosition] [float] NULL, [DataPoint] [int] NULL, CONSTRAINT [PK_CDSIM_BE] PRIMARY KEY CLUSTERED ([ID] ASC, [EquipmentID] ASC, [ReadTime] ASC) WITH …

10 sql-server sql-server-2008-r2 query-performance query-optimization execution-plan

1

FOREIGN KEYに明示的な単一のKEY値を持つMERGE JOIN（INDEX SCAN）を克服する

追加7/11問題は、MERGE JOIN中のインデックススキャンが原因でデッドロックが発生することです。この場合、トランザクションはFK親テーブルでインデックス全体のSロックを取得しようとしますが、以前は別のトランザクションがインデックスのキー値にXロックをかけています。小さな例から始めましょう（70-461コースのTSQL2012 DBが使用されています）： CREATE TABLE [Sales].[Orders]( [orderid] [int] IDENTITY(1,1) NOT NULL, [custid] [int] NULL, [empid] [int] NOT NULL, [shipperid] [int] NOT NULL, ... ) 列[custid], [empid], [shipperid]は、[Sales].[Customers], [HR].[Employees], [Sales].[Shippers]それに応じて相互に関連するパラメーターです。いずれの場合も、親テーブルの参照列にクラスター化インデックスがあります。 ALTER TABLE [Sales].[Orders] WITH CHECK ADD CONSTRAINT [FK_Orders_Customers] FOREIGN KEY([custid]) REFERENCES [Sales].[Customers] ([custid]) ALTER TABLE [Sales].[Orders] WITH CHECK ADD CONSTRAINT …

9 query-performance t-sql foreign-key deadlock query-optimization

タグ付けされた質問 「query-optimization」

タグ付けされた質問「query-optimization」