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

1週間に1度、過去5週間、ほぼ同じ時刻（早朝、人々が使用し始めたときのユーザーアクティビティに基づく場合があります）、SQL Server 2016（AWS RDS、ミラーリング）は多くのタイムアウトを開始しますクエリ。 すべてのテーブルの統計を更新すると、常にすぐに修正されます。 初回以降、すべてのテーブルのすべての統計を（毎週ではなく）毎晩更新しましたが、それでも起こりました（更新統計が実行されてから約8時間後ですが、毎日実行されるわけではありません）。 前回、クエリストアを有効にして、どの特定のクエリ/クエリプランであるかを確認できるかどうかを確認しました。私はそれを1つに絞り込むことができたと思います： そのクエリを見つけた後、この頻繁に使用されないクエリから欠落している推奨インデックスを追加しました（ただし、頻繁に使用される多くのテーブルに影響します）。 不適切なクエリプランは、インデックススキャンを実行していました（1万行のみのテーブルで）。同じスキャンを実行するために使用されたミリ秒単位で返された他のクエリプラン。新しいインデックスを作成した後の最新のクエリプランは、シークのみを行います。しかし、そのインデックスがなくても、99％の時間で数ミリ秒以内に戻りましたが、毎週、40秒以上かかりました。 タイムアウトする悪いもの：http : //brentozar.com/pastetheplan/?id=rymaWt56e タイムアウトしない以前の計画：http : //brentozar.com/pastetheplan/?id=HyN7ftcpe 新しいインデックスを使用した最新の計画：http : //brentozar.com/pastetheplan/?id=ryLuGKcag これは、2012年からSQL Server 2016に移行した後に発生し始めました。 DBCC CHECKDBはエラーを返しません。 新しいインデックスは問題を修正し、再び悪い計画を二度と選択しないようにしますか？ うまく機能する計画を「強制」する必要がありますか？ これが別のクエリ/プランで発生しないことを確認するにはどうすればよいですか？ これはより大きな問題の症状ですか？ 追加したばかりのインデックス： CREATE NONCLUSTERED INDEX idx_AppointmetnAttendee_AttendeeType ON [dbo].[AppointmentAttendee] ([UserID],[AttendeeType]) CREATE NONCLUSTERED INDEX [idx_appointment_start] ON [dbo].[Appointment] ( [ProjectID] ASC, [Start] ASC ) INCLUDE ( [ID], …

16 sql-server  execution-plan  sql-server-2016  statistics  query-store 

警告Operator usedtempdbを使用して、クエリプランでの並べ替え操作のコストを最小限に抑えるのに苦労していますto spill data during execution with spill level 2 流出レベル1で実行中に流出データに関連するいくつかの投稿を見つけましたが、レベル2ではありません。レベル1は古い統計に起因しているようですが、レベル2はどうですか？に関連するものは見つかりませんでしたlevel 2。 この記事はソート警告に関連して非常に興味深いものでした。 SQL Serverで並べ替え警告を無視しない 私のSQLサーバー？ Microsoft SQL Server 2014（SP2）（KB3171021）-12.0.5000.0（X64）2016年6月17日19:14:09 Copyright（c）Microsoft Corporation Enterprise Edition（64ビット）on Windows NT 6.3（Build 9600：）（Hypervisor） 私のハードウェア？ ハーウェアを見つけるために以下のクエリを実行します： -SQL Server 2012のハードウェア情報 SELECT cpu_count AS [Logical CPU Count], hyperthread_ratio AS [Hyperthread Ratio], cpu_count/hyperthread_ratio AS [Physical CPU Count], physical_memory_kb/1024 AS …

16 sql-server  query-performance  memory  execution-plan  sort-operator 

実行計画でキー検索（クラスター化）演算子を削除するにはどうすればよいですか？ テーブルにはtblQuotes既にクラスター化インデックス（QuoteID）と27個の非クラスター化インデックスがあるため、これ以上作成しないようにしています。 私QuoteIDはクエリにクラスター化インデックス列を入れて、それが役立つことを願っていますが、残念ながらまだ同じです。 実行計画はこちら。 またはそれを見る： これは、キールックアップオペレーターによるものです。 クエリ： declare @EffDateFrom datetime ='2017-02-01', @EffDateTo datetime ='2017-08-28' SET NOCOUNT ON SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED IF OBJECT_ID('tempdb..#Data') IS NOT NULL DROP TABLE #Data CREATE TABLE #Data ( QuoteID int NOT NULL, --clustered index [EffectiveDate] [datetime] NULL, --not indexed [Submitted] [int] NULL, [Quoted] …

16 sql-server  sql-server-2012  query-performance  execution-plan  bookmark-lookup 

スプールム SQL Serverには、いくつかの種類のスプールがあります。私が興味を持っている2つはTable SpoolとIndexスプールで、修正クエリの外です。 読み取り専用クエリ、特にネストループ結合の内側では、テーブルスプールまたはインデックススプールのいずれかを使用して、I / Oを削減し、クエリのパフォーマンスを向上させることができます。これらのスプールは、EagerまたはLazyです。あなたと私のように。 私の質問は： どの要素がテーブルとインデックススプールの選択に影響するか イーガースプールとレイジースプールのどちらを選択するか

15 sql-server  execution-plan 

「実際の実行プランを含める」でクエリを実行すると、プランは欠落しているインデックスも提案します。インデックスの詳細はMissingIndexes、XML 内のタグです。計画に複数のインデックスの提案が含まれている状況はありますか？さまざまなSQLクエリを試しましたが、2つ以上の欠落インデックスを生成するクエリを思い付くことができませんでした。

15 sql-server  index  execution-plan 

過去2日間、試行錯誤と実行計画を使用して最適化しようとして費やしたSQLクエリがありますが、役に立ちません。これを行うことを許してください。しかし、私はここに実行計画全体を掲載します。簡潔にするためと会社のIPを保護するために、クエリおよび実行プランのテーブル名と列名を汎用にするように努力しました。実行計画は、SQL Sentry Plan Explorerで開くことができます。 かなりの量のT-SQLを実行しましたが、実行プランを使用してクエリを最適化することは私にとって新しい分野であり、その方法を本当に理解しようとしました。したがって、誰かがこれを手伝って、この実行計画を解読してクエリで最適化する方法を見つける方法を説明できれば、私は永遠に感謝しています。最適化するクエリはさらに多くあります。この最初のクエリを支援するための踏み台が必要です。 これはクエリです： DECLARE @Param0 DATETIME = '2013-07-29'; DECLARE @Param1 INT = CONVERT(INT, CONVERT(VARCHAR, @Param0, 112)) DECLARE @Param2 VARCHAR(50) = 'ABC'; DECLARE @Param3 VARCHAR(100) = 'DEF'; DECLARE @Param4 VARCHAR(50) = 'XYZ'; DECLARE @Param5 VARCHAR(100) = NULL; DECLARE @Param6 VARCHAR(50) = 'Text3'; SET NOCOUNT ON DECLARE @MyTableVar TABLE …

15 sql-server  sql-server-2008  t-sql  optimization  execution-plan 

OFFSET ... FETCHSQL Server 2012で導入された新しいモデルは、シンプルで高速なページングを提供します。2つの形式が意味的に同一であり、非常に一般的であることを考慮すると、なぜまったく違いがあるのですか？ オプティマイザーが両方を認識し、それらを（簡単に）最大限に最適化すると仮定します。 OFFSET ... FETCHこれは、コストの見積もりによると2倍速い非常に単純なケースです。 SELECT * INTO #objects FROM sys.objects SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY object_id) r FROM #objects ) x WHERE r >= 30 AND r < (30 + 10) ORDER BY object_id SELECT * FROM #objects ORDER BY …

15 sql-server  sql-server-2012  execution-plan  optimization  offset-fetch 

テーブルにtは2つのインデックスがあります。 create table t (a int, b int); create type int_pair as (a int, b int); create index t_row_idx on t (((a,b)::int_pair)); create index t_a_b_idx on t (a,b); insert into t (a,b) select i, i from generate_series(1, 100000) g(i) ; any演算子ではインデックスは使用されません。 explain analyze select * from t where (a,b) = …

15 postgresql  index  optimization  postgresql-9.4  execution-plan 

サイトhttp://sqlfiddle.comに、ユーザーがクエリの未加工の実行計画を表示できる機能を展開しました。PostgreSQL、MySQL、および（ある程度）Oracleの場合、生の実行計画の出力を見ると理解できるように見えます。ただし、SQL Server（で生成されたSET SHOWPLAN_XML ON）の実行計画の出力を見ると、比較的単純なクエリであっても、大量のXMLが処理されます。次に例を示します（この「フィドル」の最後のクエリの実行計画から取得：http ://sqlfiddle.com/#!3/ 1fa93/1）： <ShowPlanXML xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan" Version="1.1" Build="10.50.2500.0"> <BatchSequence> <Batch> <Statements> <StmtSimple StatementText="
select * from supportContacts" StatementId="1" StatementCompId="1" StatementType="SELECT" StatementSubTreeCost="0.0032853" StatementEstRows="3" StatementOptmLevel="TRIVIAL" QueryHash="0x498D13A3874D9B6E" QueryPlanHash="0xD5DDBD3C2D195E96"> <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="false" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false"/> <QueryPlan CachedPlanSize="16" CompileTime="0" CompileCPU="0" CompileMemory="72"> <RelOp NodeId="0" PhysicalOp="Clustered Index Scan" LogicalOp="Clustered Index Scan" EstimateRows="3" EstimateIO="0.003125" EstimateCPU="0.0001603" …

15 sql-server  sql-server-2008-r2  execution-plan 

数十行のテーブルがあります。簡略化されたセットアップは次のとおりです CREATE TABLE #data ([Id] int, [Status] int); INSERT INTO #data VALUES (100, 1), (101, 2), (102, 3), (103, 2); そして、このテーブルを、一連のテーブル値で構成された行（変数と定数で構成される）に結合するクエリがあります。 DECLARE @id1 int = 101, @id2 int = 105; SELECT COALESCE(p.[Code], 'X') AS [Code], COALESCE(d.[Status], 0) AS [Status] FROM (VALUES (@id1, 'A'), (@id2, 'B') ) p([Id], [Code]) FULL JOIN …

14 sql-server  execution-plan 

次の表、一意のクラスター化インデックス、および統計情報が与えられます。 CREATE TABLE dbo.Banana ( pk integer NOT NULL, c1 char(1) NOT NULL, c2 char(1) NOT NULL ); CREATE UNIQUE CLUSTERED INDEX pk ON dbo.Banana (pk); CREATE STATISTICS c1 ON dbo.Banana (c1); CREATE STATISTICS c2 ON dbo.Banana (c2); INSERT dbo.Banana (pk, c1, c2) VALUES (1, 'A', 'W'), (2, 'B', 'X'), …

14 sql-server  update  execution-plan  statistics  unique-constraint 

SQLクエリの実行前にSqlCommand.Prepare（）（MSDNを参照）メソッドが広く使用されている開発者コードに出会いました。そして、これの利点は何でしょうか？ サンプル： command.Prepare(); command.ExecuteNonQuery(); //... command.Parameters[0].Value = 20; command.ExecuteNonQuery(); 私は少し遊んでトレースしました。Prepare()メソッドを呼び出した後にコマンドを実行すると、SQL Serverで次のステートメントが実行されます。 declare @p1 int set @p1=1 exec sp_prepexec @p1 output,N'@id int,@desc text',N'INSERT INTO dbo.testtable (id) VALUES (@id)',@id=20' select @p1 その後、パラメータが値を取得してSqlCommand.ExecuteNonQuery()呼び出されると、次がSql-Serverで実行されます。 exec sp_execute 1,@id=20 私には、これはステートメントがPrepare()実行されるとすぐにコンパイルされるように見えます。これの利点は何でしょうか？これは、それがプランキャッシュに入れられ、目的のパラメーター値で最終クエリが実行されるとすぐに再利用できることを意味しますか？ SqlParametersで実行されるSqlCommandsは、常にプロシージャコールでラップされることがわかりました（別の質問で説明しました）sp_executesql。これにより、SQL Serverは、パラメーター値に依存しないプランを保存および再利用できます。 これに関してprepare()は、メソッドが役に立たないのか、時代遅れののか、ここで何かが足りないのでしょうか？

14 sql-server  sql-server-2008-r2  execution-plan  prepared-statement  plan-cache 

実稼働環境でこの問題が発生しています。 Microsoft SQL Server 2008 R2（SP1）-10.50.2500.0（X64）-Windows NT 6.1（ビルド7601：Service Pack 1）上のEnterprise Edition（64ビット）。 SQL Serverは、すべての（ほぼ100％）古い実行計画を削除し、毎日一晩中（午後11:00から8:00に）再作成しています。これは、「自動更新統計」が無効状態のときにも発生していました。過去2〜3週間、「自動更新統計」をオンにしました。しかし、それはまだ起こっています。 この計画の再生成をトリガーするものは実際にはわかりませんが、手動でそれを行わないことは確かです。 計画が再生成されるタイミングと実際に一致するのは、DBメンテナンスジョブのみです。毎日のインデックスの再編成（断片化が5〜30％の場合）と毎日のインデックスの再構築（断片化が30％を超える場合） ）仕事。通常、この毎日のメンテナンスジョブは再編成のみを行います（インデックスの断片化は毎日30％を超えないため）。 影響： これらの新しく作成されたプランにより、UDF呼び出し/クエリ呼び出し（UI / Webページから呼び出される）がかなり長くなり（1秒未満ではなく数分）、セッションが積み上げられてCPUが90％近くになります。 問題は、それらのスタックしたセッションが強制的に削除された瞬間（DB側）、1）対応するすべての実行プランが手動でクリアされたとき（クエリの場合）、2）UDFが変更されたとき（関数の場合）に消えます。その瞬間からSQLサーバーによって作成された新しい計画は、翌朝同じ問題が発生するまで1日を通して完璧に機能します。また、この動作は100％一貫しているわけではなく、毎朝実際に表示されるわけではありません。しかし、4〜5日間連続して表示されている期間がありました。 この問題は、ビジネスの朝に発生します。UI/ Webページがより集中的にアクセスされる場合です。 誰がこれを引き起こしているのか、この問題を解決する方法の手がかりを持っていますか？どんな助けでも大歓迎です。

14 sql-server  sql-server-2008  execution-plan  statistics 

パフォーマンス上の理由で避けるべきものを知っていますが、表示されないようにする方法のデモとして表示される状態を表示しようとしています。 ただし、インデックスが欠落しているという警告が表示されますが、オプティマイザーは一時インデックスを作成しないことを選択します。 私が使用しているクエリは SELECT z.a FROM dbo.t5 AS z WITH(INDEX(0)) WHERE EXISTS ( SELECT y.a FROM dbo.t4 AS y WHERE y.a = z.a ) OPTION (MAXDOP 1); テーブルスキーマは次のとおりです。 CREATE TABLE dbo.t4 ( a integer NULL, b varchar(1000) NULL, p varchar(100) NULL ); CREATE TABLE dbo.t5 ( a integer NULL, b …

14 sql-server-2012  t-sql  execution-plan  index-spool 

可用性グループのプライマリでプランが強制される場合、セカンダリで実行されるクエリに適用されますか？ 私は計画強制の両方の可能性をカバーする答えを探しています： 計画ガイド クエリストアの強制計画 QS強制プランは引き継がれないことを示唆する次の記事を読みましたが、ドキュメント内で信頼できるもの、またはプランガイドに関するものを見つけることができません。 Erin Stellatoによるクエリストアと可用性グループ Vikas RanaによるAlwaysOn Readable Secondaryでのクエリデータストアの強制プランの動作 強制の決定的な証拠は存在だろうUse Planか、PlanGuideNameとPlanGuideDBの二次実行計画のプロパティ。

14 sql-server  availability-groups  execution-plan  query-store  plan-guides