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

R-tree / spatialインデックスに適しているので、特にPostgresに対してこの質問をすること。 次の表に、単語とその頻度のツリー構造（ネストされたセットモデル）を示します。 lexikon ------- _id integer PRIMARY KEY word text frequency integer lset integer UNIQUE KEY rset integer UNIQUE KEY そしてクエリ： SELECT word FROM lexikon WHERE lset BETWEEN @Low AND @High ORDER BY frequency DESC LIMIT @N カバリングインデックス(lset, frequency, word)が有効であると思いlsetますが、(@High, @Low)範囲内の値が多すぎるとうまく機能しない可能性があります。 (frequency DESC)そのインデックスを使用した検索@Nが範囲条件に一致する行を早期に生成する場合、単純なインデックスで十分な場合もあります。 しかし、パフォーマンスはパラメーター値に大きく依存するようです。 範囲(@Low, @High)が広いか狭いかに関係なく、また、頻度の高い単語が幸運にも選択された範囲内にあるかどうかにかかわらず、高速に実行する方法はありますか？ Rツリー/空間インデックスは役立ちますか？ インデックスの追加、クエリの書き換え、テーブルの再設計、制限はありません。

29 postgresql  database-design  index  query-performance 

かなり大きなレコード数（1000万から2000万行）のデータウェアハウスがあり、特定の日付の間にレコードを数えるクエリや、特定のフラグを持つレコードを数えるクエリを実行することがよくあります。 SELECT f.IsFoo, COUNT(*) AS WidgetCount FROM Widgets AS w JOIN Flags AS f ON f.FlagId = w.FlagId WHERE w.Date >= @startDate GROUP BY f.IsFoo パフォーマンスはそれほど悪くありませんが、比較的遅くなる可能性があります（コールドキャッシュで10秒程度）。 最近、私GROUP BYはインデックス付きビューで使用できることを発見し、次のようなものを試しました CREATE VIEW TestView WITH SCHEMABINDING AS SELECT Date, FlagId, COUNT_BIG(*) AS WidgetCount FROM Widgets GROUP BY Date, FlagId; GO CREATE UNIQUE CLUSTERED …

28 sql-server  index  query-performance  materialized-view 

tstzrange変数の正確な等価性が必要な更新を実行しています。〜1M行が変更され、クエリには〜13分かかります。の結果はここでEXPLAIN ANALYZE見ることができ、実際の結果はクエリプランナーが推定した結果とは大きく異なります。問題は、インデックススキャンで単一の行が返されることを期待していることです。t_range これは、範囲タイプの統計が他のタイプの統計とは異なる方法で保存されるという事実に関連しているようです。pg_stats列のビューを見ると、n_distinctis -1であり、他のフィールド（most_common_valsなどmost_common_freqs）は空です。 ただし、t_rangeどこかに統計が保存されている必要があります。完全に同等ではなくt_rangeで「within」を使用する非常に類似した更新の実行には約4分かかり、実質的に異なるクエリプランを使用します（こちらを参照）。一時テーブルのすべての行と履歴テーブルのかなりの部分が使用されるため、2番目のクエリプランは理にかなっています。さらに重要なことは、クエリプランナーがのフィルタに対してほぼ正しい行数を予測することt_rangeです。 の分布t_rangeは少し珍しいです。このテーブルを使用して別のテーブルの履歴状態を保存していますが、他のテーブルへの変更は大きなダンプで一度に発生するため、の値はあまり多くありませんt_range。の一意の値のそれぞれに対応するカウントはt_range次のとおりです。 t_range | count -------------------------------------------------------------------+--------- ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00") | 994676 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") | 36791 ["2014-06-27 07:00:00+00","2014-08-01 07:00:01+00") | 1000403 ["2014-06-27 07:00:00+00",infinity) | 36791 ["2014-08-01 07:00:01+00",infinity) | 999753 t_range上記のdistinctのカウントは完了しているため、カーディナリティは〜3Mです（このうち〜1Mは、いずれかの更新クエリの影響を受けます）。 クエリ1のパフォーマンスがクエリ2よりもはるかに低いのはなぜですか？私の場合、クエリ2が適切な代替品ですが、正確な範囲の均等性が本当に必要な場合、Postgresでよりスマートなクエリプランを使用するにはどうすればよいですか？ インデックス付きのテーブル定義（無関係な列の削除）： Column | Type | Modifiers ---------------------+-----------+------------------------------------------------------------------------------ history_id | integer | not null default nextval('gtfs_stop_times_history_history_id_seq'::regclass) …

28 postgresql  query-performance  postgresql-9.3  postgresql-performance  range-types 

ビューの内側または外側でビューをフィルタリングすると、違いが生じますか？ たとえば、これら2つのクエリに違いはありますか？ SELECT Id FROM MyTable WHERE SomeColumn = 1 または SELECT Id FROM MyView WHERE SomeColumn = 1 とMyView定義されます SELECT Id, SomeColumn FROM MyTable ソーステーブルがリンクサーバー上にある場合、答えは異なりますか？ リンクサーバーから大きなテーブル（44mil行）を2回クエリし、結果の集計を取得する必要があるため、私は尋ねています。データにアクセスするために2つのビューを作成する必要があるかどうか（クエリごとに1つ）、または単一のビューと1つのWHERE句で処理できるかどうかを知りたいです。

28 sql-server  sql-server-2005  view  query-performance 

SQL Server 2014の次のクエリプランを検討してください。 クエリプランでは、自己結合ar.fId = ar.fIdにより1行の推定値が得られます。しかし、これは論理的に矛盾する推定値は、次のとおりar有する20,608行とのちょうど1つの異なる値fId（正確に統計に反映します）。したがって、この結合は行（~424MM行）の完全な外積を生成し、クエリを数時間実行します。 SQL Serverが統計と矛盾していることが非常に簡単に証明できる見積もりを思い付く理由を理解するのに苦労しています。何か案は？ 初期調査と追加の詳細 ここでのPaulの回答に基づくと、結合のカーディナリティを推定するためのSQL 2012とSQL 2014の両方のヒューリスティックは、2つの同一のヒストグラムを比較する必要がある状況を簡単に処理できるようです。 トレースフラグ2363からの出力から始めましたが、それを簡単に理解できませんでした。以下は、SQL Serverがためにヒストグラムを比較していることを意味スニペットないfIdとbIdだけその用途に参加の選択を推定するためにfId？もしそうなら、それは明らかに正しくないでしょう。または、トレースフラグの出力を読み間違えていますか？ Plan for computation: CSelCalcExpressionComparedToExpression( QCOL: [ar].fId x_cmpEq QCOL: [ar].fId ) Loaded histogram for column QCOL: [ar].bId from stats with id 3 Loaded histogram for column QCOL: [ar].fId from stats with id 1 Selectivity: 0 完全な再現スクリプトに含まれ、このクエリをミリ秒にまで下げるいくつかの回避策を思いついたことに注意してください。この質問は、動作の理解、今後のクエリでの動作の回避方法、およびMicrosoftに提出する必要があるバグかどうかの判断に焦点を当てています。 ここで完全なREPROスクリプトは、ここにあるトレースフラグ2363年からフル出力は、ここであなたがすぐにいっぱいスクリプトを開くことなく、それらを見たい場合はクエリとテーブル定義は次のとおりです。 …

27 sql-server  query-performance  sql-server-2014  execution-plan  cardinality-estimates 

私はデータベースをステージングテーブルにロードします。このステージングテーブルから、外部キーを解決するために1-2回結合し、この行を最終テーブル（月ごとに1つのパーティションがある）に挿入します。3か月分のデータで約34億行あります。 これらの行をファイナルテーブルにステージングする最速の方法は何ですか？SSISデータフロータスク（ビューをソースとして使用し、高速ロードがアクティブになっている）またはInsert INTO SELECT ....コマンド？データフロータスクを試してみましたが、約5時間で約10億行（サーバー上の8コア/ 192 GB RAM）を得ることができ、非常に遅いと感じました。

27 sql-server  sql-server-2012  query-performance  insert 

ストアドプロシージャは、実行パスを通じて（アプリケーションのインラインSQLよりも）より効率的であることを知っています。しかし、押されたとき、私はその理由についてあまり知らない。 この技術的な理由を知りたい（後で誰かに説明できるように）。 誰も私が良い答えを策定するのを手伝ってくれますか？

27 sql-server  stored-procedures  query-performance 

PostgreSQL（9.4）データベースを使用してRuby on Railsでアプリケーションを開発しています。私のユースケースでは、アプリケーションの全体のポイントはモデル上の非常に特定の属性を検索するため、テーブルの列は非常に頻繁に検索されます。 私は現在、使用するかどうかを決定していますintegerタイプを、または単に（例えば、一般的な文字列型を使用character varying(255)、Railsのではデフォルトである私は、性能差がインデックスにどうなるかわからないよう、列に対して）。 これらの列は列挙型です。可能な値の量に対して固定サイズがあります。ほとんどの列挙の長さは5を超えません。これは、アプリケーションの存続期間中、インデックスが多少固定されることを意味します。したがって、整数と文字列のインデックスはノードの数が同じになります。 ただし、インデックス付けされる文字列の長さは約20文字で、メモリ内では整数の約5倍になります（整数が4バイトで、文字列が1文字あたり1バイトの純粋なASCIIの場合、これは成り立ちます）。私は、データベースエンジンがインデックスのルックアップを行う方法を知りませんが、それが一致するまで、それは「スキャン」の文字列に必要がある場合は、正確にそして本質的には、手段は、文字列検索が遅くなる整数のルックアップよりも5倍になるということ。整数ルックアップに一致するまでの「スキャン」は20ではなく4バイトになります。これが私が想像していることです。 ルックアップ値は（整数）4です。 スキャン.................. FOUND | レコードを取得しています... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | BYTE_8 | ... | ルックアップ値は（string） "some_val"（8バイト）です。 走査................................................. ....................................見つかった| レコードを取得しています... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 …

26 postgresql  index  query-performance  index-tuning  postgresql-performance 

私には、SARGabilityに関する興味深い質問があります。この場合、2つの日付列の違いに関する述語を使用することです。セットアップは次のとおりです。 USE [tempdb] SET NOCOUNT ON IF OBJECT_ID('tempdb..#sargme') IS NOT NULL BEGIN DROP TABLE #sargme END SELECT TOP 1000 IDENTITY (BIGINT, 1,1) AS ID, CAST(DATEADD(DAY, [m].[severity] * -1, GETDATE()) AS DATE) AS [DateCol1], CAST(DATEADD(DAY, [m].[severity], GETDATE()) AS DATE) AS [DateCol2] INTO #sargme FROM sys.[messages] AS [m] ALTER TABLE [#sargme] ADD …

24 sql-server  index  query-performance 

Itzik Ben-Ganの PCMagでこれらの記事を読みました。 シークし、スキャンしますパートI：オプティマイザがシークを最適化しない場合、 スキャンしますパートII：昇順キー 現在、すべてのパーティションテーブルで「グループ化された最大」問題が発生しています。Itzik Ben-Ganが提供するトリックを使用して max（ID）を取得しますが、実行されない場合があります。 DECLARE @MaxIDPartitionTable BIGINT SELECT @MaxIDPartitionTable = ISNULL(MAX(IDPartitionedTable), 0) FROM ( SELECT * FROM ( SELECT partition_number PartitionNumber FROM sys.partitions WHERE object_id = OBJECT_ID('fct.MyTable') AND index_id = 1 ) T1 CROSS APPLY ( SELECT ISNULL(MAX(UpdatedID), 0) AS IDPartitionedTable FROM fct.MyTable s WHERE $PARTITION.PF_MyTable(s.PCTimeStamp) …

22 sql-server  query-performance  partitioning 

この質問は私の古い質問に関連しています。以下のクエリの実行には10〜15秒かかりました。 SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [company].dbo.[customer] WHERE (Charindex('123456789',CAST([company].dbo.[customer].[Phone no] AS VARCHAR(MAX)))>0) 一部の記事では、インデックスを使用CASTしてCHARINDEXもメリットが得られないことがわかりました。またLIKE '%abc%'、インデックスを使用してもメリットはありませんが、インデックスを使用してもメリットがないという記事もありますLIKE 'abc%'。 http://bytes.com/topic/sql-server/answers/81467-using-charindex-vs-like-where /programming/803783/sql-server-index-any-improvement-for -like-queries http://www.sqlservercentral.com/Forums/Topic186262-8-1.aspx#bm186568 私の場合、クエリを次のように書き換えることができます。 SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [company].dbo.[customer] WHERE [company].dbo.[customer].[Phone no] LIKE '%123456789%' このクエリは、前のクエリと同じ出力を提供します。columnの非クラスター化インデックスを作成しましたPhone no。このクエリを実行すると、わずか1秒で実行されます。これは、以前の14秒と比較して大きな変化です。 どのようにLIKE '%123456789%'インデックスからの利点は？ リストされた記事にパフォーマンスが改善されないと記載されているのはなぜですか？ 使用するクエリを書き直そうとしましたCHARINDEXが、パフォーマンスはまだ遅いです。クエリのCHARINDEXように表示されるのに、なぜインデックス付けのメリットがないのLIKEですか？ を使用したクエリCHARINDEX： SELECT [customer].[Customer name],[customer].[Sl_No],[customer].[Id] FROM [Company].dbo.[customer] WHERE ( Charindex('9000413237',[Company].dbo.[customer].[Phone no])>0 ) 実行計画： を使用したクエリLIKE： SELECT [customer].[Customer …

22 sql-server-2008-r2  index  query-performance 

関数で（または関数として）使用でき、n値のすべての組み合わせを取得できるクエリが必要です。そして、長さkのすべての組み合わせ（k = 1..n）が必要です。 拡張されたサンプル入力と結果により、入力は2ではなく3つの値になります-ただし、入力値の数は1からnまで変化する場合があります。 例：入力：複数行の1列の値を持つテーブル Value (nvarchar(500)) ------ Ann John Mark 出力＃1：1つの列に値が連結されたテーブル Ann John Mark Ann,John John,Mark Ann,Mark Ann,John,Mark

22 sql-server  query-performance 

次のようなクエリがあるとします。 select a.*,b.* from a join b on a.col1=b.col1 and len(a.col1)=10 上記のクエリがハッシュ結合を使用し、残差があると仮定すると、プローブキーはにcol1なり、残差はになりますlen(a.col1)=10。 しかし、別の例を見ると、プローブと残差の両方が同じ列であることがわかりました。以下は、私が言おうとしていることの詳細です。 クエリ： select * from T1 join T2 on T1.a = T2.a プローブと残差が強調表示された実行計画： テストデータ： create table T1 (a int, b int, x char(200)) create table T2 (a int, b int, x char(200)) set nocount on declare @i int …

21 sql-server  query-performance  execution-plan  database-internals 

カバリングインデックスを介してインデックス付きビューから結果を返すストアドプロシージャがあります。通常、高速（約10ミリ秒）で実行され、最大8秒まで実行されることもあります。 ランダム実行の例を次に示します（注：これは低速ではありませんが、クエリテキストは、渡される値を除いて同じです）。 declare @p2 dbo.IdentityType insert into @p2 values(5710955) insert into @p2 values(5710896) insert into @p2 values(5710678) insert into @p2 values(5710871) insert into @p2 values(5711103) insert into @p2 values(6215197) insert into @p2 values(5710780) exec ListingSearch_ByLocationAndStatus @statusType=1,@locationIds=@p2 スプロックは次のとおりです。 ALTER PROCEDURE [dbo].[ListingSearch_ByLocationAndStatus] @LocationIds IdentityType READONLY, @StatusType TINYINT AS BEGIN SET NOCOUNT ON; …

20 sql-server  sql-server-2012  query-performance  azure-vm 

次のクエリプランスニペットでは、Concatenation演算子の行推定値はである必要があること~4.3 billion rows、またはその2つの入力の行推定値の合計であることは明らかです。 しかし、の推定値は~238 million rows、最適につながる、生成されるSort/ Stream AggregatetempdbのにデータのGB数百をこぼし戦略。この場合の論理的に一貫した推定は、を生成しHash Aggregate、流出を除去し、クエリパフォーマンスを劇的に改善します。 これはSQL Server 2014のバグですか？入力よりも低い見積もりが合理的である有効な状況はありますか？どのような回避策が利用可能ですか？ ここで完全なクエリプラン（匿名化）が。出力QUERYTRACEON 2363または類似のトレースフラグを提供するためにこのサーバーにsysadminアクセスすることはできませんが、役立つ場合は管理者からこれらの出力を取得できる場合があります。 データベースは互換性レベル120にあるため、新しいSQL Server 2014 Cardinality Estimatorを使用しています。 統計は、データがロードされるたびに手動で更新されます。データ量を考えると、現在デフォルトのサンプリングレートを使用しています。より高いサンプリングレート（またはFULLSCAN）が影響を与える可能性があります。

20 sql-server  query-performance  sql-server-2014  concat  cardinality-estimates