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

これらの質問と与えられた回答に基づいて： SQL 2008 Server-非常に大きなテーブルに接続されている可能性があるパフォーマンスの損失 履歴データを含む大きなテーブルは、SQL Server 2008 Stdを過剰に割り当てます。メモリ-他のデータベースのパフォーマンス低下 データベースSupervisionPに次のように定義されたテーブルがあります。 CREATE TABLE [dbo].[PenData]( [IDUkazatel] [smallint] NOT NULL, [Cas] [datetime2](0) NOT NULL, [Hodnota] [real] NULL, [HodnotaMax] [real] NULL, [HodnotaMin] [real] NULL, CONSTRAINT [PK_Data] PRIMARY KEY CLUSTERED ( [IDUkazatel] ASC, [Cas] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS …

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

いくつかの数値といくつかの追加データを含むPostgreSQL 9.3テーブルがあります。 CREATE TABLE mytable ( myid BIGINT, somedata BYTEA ) このテーブルには現在約1,000万のレコードがあり、1GBのディスク容量を使用します。myid連続していません。 100000の連続番号の各ブロックにある行の数を計算したいと思います。 SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000; これは約3500行を返します。 クエリプランでまったく言及されていなくても、特定のインデックスが存在すると、このクエリが大幅に高速化されることに気づきました。インデックスなしのクエリプラン： db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------- GroupAggregate (cost=1636639.92..1709958.65 …

8 postgresql  index  index-tuning  count  execution-plan 

世帯の詳細が記載されたテーブルと、その世帯に関連するすべての人物の詳細が記載されたテーブルがあります。世帯テーブルには、2つの列を使用して定義された主キーがあります- [tempId,n]。personテーブルには、3つの列を使用して定義された主キーがあります。[tempId,n,sporder] 主キーのクラスター化インデックスによって指示された並べ替えを使用して、各世帯[HHID]および各人の[PERID]レコードに一意のIDを生成しました（以下のスニペットはPERIDを生成するためのものです）： ALTER TABLE dbo.persons ADD PERID INT IDENTITY CONSTRAINT [UQ dbo.persons HHID] UNIQUE; 今、私の次のステップは、各人を対応する世帯に関連付けることです。マップ[PERID]には[HHID]。2つのテーブル間の横断歩道は、2つの列に基づいています[tempId,n]。このため、次の内部結合ステートメントがあります。 UPDATE t1 SET t1.HHID = t2.HHID FROM dbo.persons AS t1 INNER JOIN dbo.households AS t2 ON t1.tempId = t2.tempId AND t1.n = t2.n; 私は合計で1928783世帯の記録と5239842人の記録を持っています。現在、実行時間は非常に長くなっています。 さて、私の質問： このクエリをさらに最適化することは可能ですか？より一般的には、結合クエリを最適化するための経験則は何ですか？ より良い実行時間で私が望む結果を達成できる別のクエリ構造はありますか？ 私がしている実行計画アップロード SQLPerformance.comに全体のスクリプトは、SQL Server 2008によって生成されたが

8 sql-server  optimization  join  execution-plan 

見積もりプランを実際のプランではなくプランキャッシュに保存するというこの決定の背後にある多くの理由を考えることができます。しかし、「正しい」答えが見つかりません。

8 sql-server  execution-plan  plan-cache 

私が理解しているように、SQL Server（または実際には他のRDBMS）のクエリオプティマイザーは、データベースの下のストレージのパフォーマンスを認識せず、すべてのストレージのコストが等しいかのように判断します。それは正確ですか、または考慮に入れられているストレージパフォーマンスの知識はありますか？ 完全に不自然な例で、テーブルの行が瞬時のアクセス時間でSANのSSDドライブに保存されているとしましょう。インデックスは極端に過負荷のSASドライブに保存されているため、ディスクが飽和状態になり、ディスクキューが一定になります。RDBMSが実行プランを生成するとき、インデックス操作よりもテーブルスキャンを優先する可能性が高いですか（または、SASディスクでのIOが少ないため、カバーするインデックスとは対照的に、スキニーインデックスおよび関連するテーブルルックアップ）。 その答えは確かなものだと思いますが、「オプティマイザが賢くなったり、ディスクパフォ​​ーマンスを認識したりする可能性はない」と思いますが、そこにいる誰かが確かに知っているかどうかを確認したかっただけです。SQL Serverを使用していますが、どのデータベースシステムにも興味があります。

8 execution-plan  storage 

SQL Serverのマルチステートメントストアドプロシージャのパフォーマンスの問題を修正しています。時間をかけるべき部分を知りたい。 クエリコストの読み取り方法から理解しましたが、それは常にパーセントですか？SSMSに実際の実行計画を含めるように指示された場合でも、「クエリコスト（バッチに対する）」の数値はコスト見積もりに基づいており、実際とはかけ離れている場合があります。 クエリパフォーマンスの測定：「実行プランのクエリコスト」と「実行時間」から、ストアドプロシージャの呼び出しをSET STATISTICS TIMEステートメントで囲むことができることがわかり、Messagesペインに次のようなリストが表示されます。 SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 1 ms. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. [etc] SQL Server Execution Times: CPU time = 187 ms, elapsed time = 206 …

8 sql-server  query-performance  ssms  execution-plan 

これは、主キーで指定されたソート順から派生した質問ですが、ソートはSELECTで実行されます。 @Catcallは、ストレージの順序（クラスター化インデックス）と出力の順序についてこれを述べています。 多くの人々は、クラスター化インデックスが出力のソート順を保証すると信じています。しかし、それはそうではありません。ディスク上のストレージの順序を保証します。 たとえば、このブログ投稿をご覧ください。 Hugo Kornelisによるブログ投稿を読みましたが、インデックスがSQLサーバーが特定の順序でレコードを読み取ることを保証するものではないことを理解しています。しかし、自分のシナリオではこれを想定できないことを受け入れるのに苦労していますか？ CREATE TABLE [dbo].[SensorValues]( [DeviceId] [int] NOT NULL, [SensorId] [int] NOT NULL, [SensorValue] [int] NOT NULL, [Date] [int] NOT NULL, CONSTRAINT [PK_SensorValues] PRIMARY KEY CLUSTERED ( [DeviceId] ASC, [SensorId] ASC, [Date] DESC ) WITH ( FILLFACTOR=75, DATA_COMPRESSION = PAGE, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, …

8 sql-server  execution-plan  clustered-index  sorting 

特定のクエリの実際のクエリプランをキャプチャしました。 その後、いくつかの変更（統計の更新を含む）を行い、その特定のクエリを再実行しました。現在、実際のクエリプランは異なります（これは理にかなっています）。 クエリの実行速度が大幅に向上しました。他の変更（IO設定、VM設定の変更、SQLインスタンスの再起動など）もパフォーマンスの向上を引き起こしている可能性があるため、新しい実行プランがこれと関係があるかどうか知りたいです。これをテストするためにもう一度クエリを実行し、SQL Serverに古い実行プランを強制的に使用させます。 質問：ユーザー指定の実行プランでクエリを再実行する方法、またはそのようなプランから直接クエリを実行する方法はありますか？ これが私がこれを理解しようとしたものです： 私はオフィスで入手できる本（Professional SQL Server 2012の内部とトラブルシューティング、Microsoft SQL Server 2012のクエリ）を検索しました。 Google検索、たとえば「特定のクエリプランに基づいてクエリを実行」 DBA.SEは、「クエリプランの実行」や「実行プランの再実行」などの検索を行います。 そして最後に、以前に私の質問に何度も回答した質問です。「質問を投稿する」をクリックする前に、「すでに質問の回答がある可能性がある質問」を注意深く確認してください:-) つまり、これは可能ですか？もしそうなら：どのように？

7 sql-server  sql-server-2012  execution-plan