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

以下のこの質問の内容を自分の状況に適用しようとしていますが、可能であれば、演算子Hash Match（Inner Join）をどのようにして取り除くことができるのか、少し混乱しています。 SQL Serverクエリのパフォーマンス-ハッシュマッチ（内部結合）の必要性の排除 私は10％の費用に気づき、それを減らすことができるかどうか疑問に思っていました。以下のクエリプランを参照してください。 この作業は、今日調整しなければならなかったクエリサッドから来ています。 SELECT c.AccountCode, MIN(d.CustomerSID) FROM Stage.Customer c INNER JOIN Dimensions.Customer d ON c.Email = d.Email OR ( c.HomePostCode = d.HomePostCode AND c.StrSurname = d.strSurname ) GROUP BY c.AccountCode これらのインデックスを追加した後： --------------------------------------------------------------------- -- Create the indexes --------------------------------------------------------------------- CREATE NONCLUSTERED INDEX IDX_Stage_Customer_HOME_SURNAME_INCL ON Stage.Customer(HomePostCode ,strSurname) INCLUDE (AccountCode) …

9 sql-server  sql-server-2014  index  query-performance  execution-plan 

パーティション分割を使用して、ロックのためにOLTPシステムエクスペリエンスがブロックされる量を減らし、パーティションIDに基づいて作業テーブルを100個のパーティションに分割します。ただし、テスト中に、実行プランが予想したとおりに選択されていないことがわかりました。 テストシナリオは、300,000件の連絡先レコード（各連絡先のデータは2つのテーブルに分割されています）を持つ単一の顧客であり、すべて単一のパーティションに存在し、顧客のパーティションで500の特定の行を検索するクエリがあります。ハッシュ一致のようなものが計画のかなり早い段階で不要な299,500を排除することを期待しますが、SQL Serverはテーブル全体のレコード数を取得し、すべてのパーティションで平均化することを選択しているようです。処理する多くのレコード。これにより、ネストされたループが選択され、プロセスのかなり後の方で不要なレコードが削除されます。通常、これには、パーティション分割されていないテーブルに対する同じクエリの9倍の時間がかかります。 奇妙なことに、selectにオプション（再コンパイル）を追加すると賢明な計画が得られますが、なぜこれが違いを生むのか途方に暮れています。これはストアドプロシージャではありません。テスト中に、各テストを実行する前にプロシージャキャッシュをクリアします。 この動作は、関係するテーブルが分割されていない場合には見られません。つまり、推定される行数が実際の数と一致するため、毎回適切なプランが選択されます。 この動作についての洞察はいただければ幸いです。 スキーマのセットアップ： USE [Scratch] GO CREATE SCHEMA part GO CREATE PARTITION FUNCTION [ContactPartition](smallint) AS RANGE LEFT FOR VALUES (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, …

9 sql-server  sql-server-2012  partitioning  execution-plan 

転換点の問題に最近遭遇し、クエリオプティマイザが検索列の非クラスタ化インデックスを単に無視するため、数秒以内に実行を完了するために使用されていた一部のレポートクエリが2分以上かかっています。以下のクエリの例： select top 100 * from [dbo].[t_Call] where ID > 0 and throwtime between '3/20/2014 7:00:00 AM' and '3/24/2014 6:59:59 AM' order by id ID列は、インデックスクラスタ化されたThrowtime非クラスタ化インデックスを持っています。この場合、クエリプランと非クラスター化インデックスthrowtimeをID変更するのではなく、順序付けを使用していることに気付きました。また、古いデータの一部をアーカイブすることも計画しています（現在、20 mln行あります!!）。しかし、アプリケーションでこれらの変更を行うにはしばらく時間がかかります。アプリケーションレベルで変更を加えずに、レポートを適度に高速に実行する方法を見つける必要があります（まあ、それは人生です）。 プランガイドを入力してください。非クラスター化インデックスのクエリヒントを使用して以下のプランガイドを作成しましたが、何らかの理由で、非クラスター化インデックスがまだ使用されていません。何か不足していますか？ EXEC sp_create_plan_guide @name = N'[prod2reports_callthrowtime]', @stmt = N'select top 100 * from [dbo] . [t_Call] where ID > @0 and @1 < = …

9 sql-server  query-performance  execution-plan  plan-guides 

お客様の1人が新しいサーバーにアップグレードしました。 特定のストアドプロシージャを初めて実行すると、実行に3分以上かかります。後続の実行は1秒未満です。 これにより、最初の3分間は主に実行計画の計算に費やされると思います。その後の実行では、キャッシュされたプランを使用して即座に実行されます。 テストデータベースでは、同じ手順の計画を計算するのに約5秒かかります。 プラン自体にはひどいものは何もありません。ただし、プランはクエリの実行にかかる時間を示しており、計算自体は行わないため、関連性があるとは思いません。 サーバーは24ギガバイトのメモリを備えた16コアです。CPUやメモリの負荷が大きくなることはありません。 特定のデータベースでのみこのような遅い計算を引き起こしているのは何ですか？ 問題の原因を特定するためにどのような手順を実行できますか？ 編集する したがって、サーバーにアクセスして、SET SHOWPLAN_XML ONを指定してクエリを実行できました。 クエリのCompileTimeがクエリ実行時間の99％を占めていることを確認できます。StatementOptmEarlyAbortReasonがある「タイムアウト」理由はMemoryLimitExceededされ、そのデータベースのコピーを持つ我々のテストデータベースに、。

9 sql-server  sql-server-2008  execution-plan 

ツリー構造で再帰CTEを使用して、ツリー内の特定のノードのすべての子孫をリストしています。WHERE句にリテラルノード値を書き込むと、SQL Serverは実際にその値にのみCTEを適用し、実際の行数が少ないクエリプランなどを提供します。 ただし、値をパラメーターとして渡すと、CTEが実現（スプール）され、事実の後でフィルター処理されるようです。 私は計画を間違って読んでいた可能性があります。パフォーマンスの問題には気づきませんでしたが、CTEの実現により、特にビジーなシステムでは、より大きなデータセットで問題が発生する可能性があると心配しています。また、私は通常、このトラバーサルをそれ自体で複合します。祖先までトラバースし、子孫まで戻ります（すべての関連ノードを確実に収集するため）。私のデータが原因で、「関連」ノードの各セットはかなり小さいため、CTEの実現は意味がありません。また、SQL ServerがCTEを実現しているように見える場合、その「実際の」数には非常に多くの数値が含まれています。 クエリのパラメーター化されたバージョンをリテラルバージョンのように機能させる方法はありますか？CTEを再利用可能なビューにしたいと考えています。 リテラルを使用したクエリ： CREATE PROCEDURE #c AS BEGIN; WITH descendants AS (SELECT t.ParentId Id ,t.Id DescendantId FROM #tree t WHERE t.ParentId IS NOT NULL UNION ALL SELECT d.Id ,t.Id DescendantId FROM descendants d JOIN #tree t ON d.DescendantId = t.ParentId) SELECT d.* FROM descendants d WHERE …

8 sql-server  optimization  execution-plan  cte  recursive 

現在、トランザクションテーブルを設計しています。各行の現在までの合計を計算する必要があり、パフォーマンスが低下する可能性があることに気付きました。そこで、テスト用に100万行のテーブルを作成しました。 CREATE TABLE [dbo].[Table_1]( [seq] [int] IDENTITY(1,1) NOT NULL, [value] [bigint] NOT NULL, CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED ( [seq] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO そして、最近の10行とその現在までの合計を取得しようとしましたが、約10秒かかりました。 --1st attempt SELECT TOP 10 seq …

8 sql-server  database-design  t-sql  query-performance  execution-plan 

私はそれが読み取り専用些細な計画はシンプルなパラメータ化することができ、そしてすべてのクエリは、（計画が簡易であっても）ではないことをパラメータ化されたシンプルなことができます。 では、なぜこの計画は完全な最適化と単純なパラメータ化を同時に示しているのでしょうか？

8 sql-server  execution-plan  trivial-plan  simple-parameterization 

特定のクエリで使用されている実行プランに問題があるため、CPUスパイクが100％になるという大きな問題があります。私は今、自分で解決するのに数週間を費やしています。 私のデータベース 私のサンプルDBには、3つの簡略化されたテーブルが含まれています。 [データ・ロガー] CREATE TABLE [model].[DataLogger]( [ID] [bigint] IDENTITY(1,1) NOT NULL, [ProjectID] [bigint] NULL, CONSTRAINT [PK_DataLogger] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] 【インバーター】 CREATE TABLE [model].[Inverter]( [ID] [bigint] IDENTITY(1,1) NOT NULL, [SerialNumber] [nvarchar](50) NOT NULL, CONSTRAINT [PK_Inverter] …

8 query-performance  sql-server-2016  execution-plan 

式SQLite3を使用して（3.18）でインデックスを作成しようとしていますjson_extract。私の目的は、結果を生成するためにインデックスのみを必要とするクエリを実行することです。これは、json_extract大きなデータセットや値を操作するときにパフォーマンスを低下させる高価な操作であるためです。私は自分のニーズに合うカバリングインデックスが必要だと結論しました。 ステップ1-通常のテーブル構造を使用して理論をテストする CREATE TABLE Player ( Id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, FirstName TEXT NOT NULL, MiddleName TEXT, LastName TEXT NOT NULL ); CREATE INDEX Player_FirstName ON Player ( FirstName ASC, LastName ASC ); EXPLAIN QUERY PLAN SELECT FirstName, LastName FROM Player WHERE LENGTH(LastName) > 10 ORDER BY FirstName …

8 index  optimization  execution-plan  sqlite 

実際の実行プランを見ると、クエリの所要時間が1秒未満であっても、インデックスが不足していることがわかります。 SELECT Account.AccountID, Account.Name FROM account LEFT OUTER JOIN accountfeaturesetting afs ON afs.accountid = account.accountid and afs.featureid = 'Schedules' and afs.settingid = 'EditReasons' WHERE ISNULL(afs.Value, '0') = '0' AND EXISTS (SELECT 1 FROM program WHERE program.AccountID = account.AccountID AND program.Active = 1 AND (program.ScheduleEditReasonFlags <> 0 OR program.ScheduleEditReasonFields <> 0)) …

8 sql-server  index  execution-plan 

一部のクエリの実際の実行計画を見ると、WHERE句で使用されているリテラル定数が、スカラー計算と定数スキャンのネストされたチェーンとして表示されていることに気づきました。 これを再現するには、次の表を使用します CREATE TABLE Table1 ( [col1] [bigint] NOT NULL, [col2] [varchar](50) NULL, [col3] [char](200) NULL ) CREATE NONCLUSTERED INDEX IX_Table1 ON Table1 (col1 ASC) その中にいくつかのデータがあります： INSERT INTO Table1(col1) VALUES (1),(2),(3), (-9223372036854775808), (9223372036854775807), (2147483647),(-2147483648) 次の（ナンセンス）クエリを実行すると： SELECT a.col1, a.col2 FROM Table1 a, Table1 b WHERE b.col1 > 2147483648 インデックスシークとスカラー計算（定数から）の結果で、ネストされたループの描画を行うことがわかります。 リテラルがmaxintよりも大きいことに注意してください。それは書くのに役立ちますCAST(2147483648 as …

8 sql-server  sql-server-2014  execution-plan  cast 

私は節からのこの質問に答えようとしていましたが、オプションです。しかし、計画のオペレーターに行き詰まっています。以下は実行計画のスクリーンショットです。 ご覧のとおり、クエリプランにはBMK演算子がありますが、計算方法は示されていません。 手順は、私がこれまで試してみました： 私はBMK1000を探し始めたが、それは同じで質問の束を示しoperator.finally私は1つの見つかったスレッドあなたがしている参照が保たれますヒープ内の保管場所であることを」BMKを語りますクラスターキーの代わりに非クラスター化インデックスを使用します。 "..しかし、これがどのように私と関連しているかはわかりません。インデックスがないためです。 質問： BMK演算子とは何であり、それはどのように計算されます。任意のポインターも役立ちます ここに問題を再現するSQLFiddleがあります

8 sql-server  execution-plan  operator 

SQL Server 2012で実際のクエリを簡略化したバージョンを以下に示します。コンテナテーブルからデータを選択するときに、シーク述語にスカラー演算子があります。 このシーク述語でのスカラー演算子の目的は何ですか？ CREATE TABLE #EligibleOrders (OrderID INT PRIMARY KEY, StatusCD CHAR(3), CreatedOnDate DATETIME ) --insert logic into #EligibleOrders --Final Query SELECT T2.OrderID ,olic.LineItemID, SUM(c.quantity) AS ShippedQty, COUNT(DISTINCT c.ContainerID) AS ShippedCases FROM #EligibleOrders T2 INNER JOIN dbo.OrderLineItemContainers (NOLOCK) AS olic ON olic.OrderID = T2.OrderID INNER JOIN dbo.Containers (NOLOCK) AS …

8 sql-server  sql-server-2012  execution-plan 

以下のクエリを考えてみましょう： CREATE PROC dbo.GetPage @orderid AS INT = 0, -- anchor sort key @pagesize AS BIGINT = 25 AS SELECT TOP (@pagesize) orderid, orderdate, custid, empid FROM dbo.Orders WHERE orderid > @orderid ORDER BY orderid; exec GetPage 25,25 上記のクエリに対してSET STATISTICS IOが返されました： (25 row(s) affected) Table 'Orders'. Scan count 1, logical …

8 sql-server  execution-plan  database-internals  sql-server-2016 

私は実行計画について学び、さまざまなクエリを試し、それらのパフォーマンスを比較して、これに遭遇しました： SELECT StatisticID FROM ( SELECT StatisticID, ROW_NUMBER() OVER (ORDER BY StatisticID) AS rn FROM FTCatalog.Statistic ) AS T WHERE T.rn <= 1000 ORDER BY rn SELECT TOP 1000 StatisticID FROM FTCatalog.Statistic ORDER BY StatisticID どちらも同じ結果セットを返しますが、最初の方が実行速度が速く、リソースの消費量も少なくなります（少なくともSSMSはそれを教えてくれます）。ここでは実行計画を示します。 SQLクエリプランエクスプローラーとの比較： 実際に舞台裏で何が起こっているのか、なぜ結果が異なるのかについて誰かに洞察を与えることはできますか？他に必要なものがあれば、お知らせください。 ありがとう、エヴァルダス。

8 sql-server  query-performance  execution-plan