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

必要な結果を生成するために、いくつかのテーブルをサブ選択ステートメントと一緒に結合する非常に大きなクエリを必要とする状況があります。 私の質問は、複数の小さなクエリを使用することを検討し、複数の呼び出しでDBにクエリを実行して論理演算をアプリケーション層に持ち込む必要がありますか？ たとえば、次のクエリを検討してください。 SELECT * FROM `users` WHERE `user_id` IN (SELECT f2.`friend_user_id` FROM `friends` AS f1 INNER JOIN `friends` AS f2 ON f1.`friend_user_id` = f2.`user_id` WHERE f2.`is_page` = 0 AND f1.`user_id` = "%1$d" AND f2.`friend_user_id` != "%1$d" AND f2.`friend_user_id` NOT IN (SELECT `friend_user_id` FROM `friends` WHERE `user_id` = "%1$d")) AND …

13 mysql  query-performance  join  scalability 

PostgreSQL 9.6のクエリ計画に問題があります。私のクエリは次のようになります： SET role plain_user; SELECT properties.* FROM properties JOIN entries_properties ON properties.id = entries_properties.property_id JOIN structures ON structures.id = entries_properties.entry_id WHERE structures."STRUKTURBERICHT" != '' AND properties."COMPOSITION" LIKE 'Mo%' AND ( properties."NAME" LIKE '%VASP-ase-preopt%' OR properties."CALCULATOR_ID" IN (7,22,25) ) AND properties."TYPE_ID" IN (6) 上記で使用したテーブルに対して行レベルのセキュリティを有効にしています。 を使用するset enable_nestloop = Trueと、クエリプランナーはネストループを実行し、合計実行時間は約37秒になります。https：//explain.depesz.com/s/59BR をset enable_nestloop …

13 postgresql  query-performance  join  postgresql-9.6  row-level-security 

station_logsPostgreSQL 9.6データベースにテーブルがあります。 Column | Type | ---------------+-----------------------------+ id | bigint | bigserial station_id | integer | not null submitted_at | timestamp without time zone | level_sensor | double precision | Indexes: "station_logs_pkey" PRIMARY KEY, btree (id) "uniq_sid_sat" UNIQUE CONSTRAINT, btree (station_id, submitted_at) それぞれlevel_sensorについてsubmitted_at、に基づいて最後の値を取得しようとしていますstation_id。固有のstation_id値は約400 個、1日あたり約20,000行station_idです。 インデックスを作成する前に： EXPLAIN ANALYZE SELECT DISTINCT ON(station_id) …

13 postgresql  query-performance  greatest-n-per-group  postgresql-9.6 

私のアプリケーションには、「ファイル」テーブルで検索を実行するクエリがあります。 テーブル "files"は、 "f"。 "created"でパーティション分割されています（テーブル定義を参照してください。クライアント19には〜26,000,000行あります（ "f"。 "cid = 19）。 ここでのポイントは、このクエリを実行する場合です。 SELECT "f"."id" AS "FileId" , "f"."name" AS "FileName" , "f"."year" AS "Fileyear" , "f"."cid" AS "clientId" , "f"."created" AS "FileDate" , CASE WHEN ("vnVE0"."value" is not null AND "vnVE0"."value" != '') THEN CAST("vnVE0"."value" AS decimal(28,2)) ELSE 0 END AS "keywordValueCol0_numeric" …

12 query-performance  azure-sql-database 

クエリに特定のプランを使用するようにSQL Serverをだます方法があるかどうかを確認しようとしています。 1.環境 異なるプロセス間で共有されるデータがあるとします。したがって、多くのスペースをとるいくつかの実験結果があるとします。その後、各プロセスについて、使用する実験結果の年/月を特定します。 if object_id('dbo.SharedData') is not null drop table SharedData create table dbo.SharedData ( experiment_year int, experiment_month int, rn int, calculated_number int, primary key (experiment_year, experiment_month, rn) ) go これで、すべてのプロセスについて、テーブルにパラメーターが保存されました if object_id('dbo.Params') is not null drop table dbo.Params create table dbo.Params ( session_id int, experiment_year int, experiment_month int, …

12 sql-server  query-performance  sql-server-2016  functions 

シンプルなDB構造（オンラインフォーラム用）： CREATE TABLE users ( id integer NOT NULL PRIMARY KEY, username text ); CREATE INDEX ON users (username); CREATE TABLE posts ( id integer NOT NULL PRIMARY KEY, thread_id integer NOT NULL REFERENCES threads (id), user_id integer NOT NULL REFERENCES users (id), date timestamp without time zone NOT NULL, …

12 postgresql  query-performance  postgresql-9.6 

サーバーで実行するのに約3時間かかるクエリがありますが、並列処理を利用していません。（で約115万レコード、dbo.Deidentifiedで300レコードdbo.NamesMultiWord）。サーバーは8つのコアにアクセスできます。 UPDATE dbo.Deidentified WITH (TABLOCK) SET IndexedXml = dbo.ReplaceMultiWord(IndexedXml), DE461 = dbo.ReplaceMultiWord(DE461), DE87 = dbo.ReplaceMultiWord(DE87), DE15 = dbo.ReplaceMultiWord(DE15) WHERE InProcess = 1; そしてReplaceMultiword、次のように定義された手順です。 SELECT @body = REPLACE(@body,Names,Replacement) FROM dbo.NamesMultiWord ORDER BY [WordLength] DESC RETURN @body --NVARCHAR(MAX) ReplaceMultiword並行計画の形成を防ぐことへの呼びかけはありますか？これを書き換えて並列処理を可能にする方法はありますか？ ReplaceMultiword 置換の一部は他の置換の短いバージョンであり、最長一致が成功するようにするため、降順で実行されます。 たとえば、「ジョージワシントン大学」と「ワシントン大学」の他の大学があります。「ワシントン大学」の試合が最初であれば、「ジョージ」は取り残されます。 技術的にはCLRを使用できますが、その方法はよくわかりません。

12 sql-server  query-performance  sql-server-2016  parallelism 

スカラーUDFの結果に対してフィルタリングする必要があるクエリがあります。クエリは単一のステートメントとして送信する必要があるため（UDF結果をローカル変数に割り当てることができません）、TVFを使用できません。スカラーUDFによって引き起こされるパフォーマンスの問題を認識しています。これには、計画全体を連続的に実行すること、過剰なメモリ許可、カーディナリティー推定の問題、インライン化の欠如が含まれます。この質問については、スカラーUDFを使用する必要があると想定してください。 UDF自体は呼び出すのにかなり費用がかかりますが、理論的には、関数を一度計算するだけで済むように、オプティマイザーによってクエリを論理的に実装できます。この質問の非常に単純化された例をモックアップしました。次のクエリは、マシンで実行するのに6152ミリ秒かかります。 SELECT x1.ID FROM dbo.X_100_INTEGERS x1 WHERE x1.ID >= dbo.EXPENSIVE_UDF(); クエリプランのフィルター演算子は、関数が行ごとに1回評価されたことを示しています。 DDLおよびデータ準備： CREATE OR ALTER FUNCTION dbo.EXPENSIVE_UDF () RETURNS INT AS BEGIN DECLARE @tbl TABLE (VAL VARCHAR(5)); -- make the function expensive to call INSERT INTO @tbl SELECT [VALUE] FROM STRING_SPLIT(REPLICATE(CAST('Z ' AS VARCHAR(MAX)), 20000), ' '); RETURN 1; …

12 sql-server  query-performance  functions 

外部に対する次のクエリは、320万行で実行するのに約5秒かかります。 SELECT x."IncidentTypeCode", COUNT(x."IncidentTypeCode") FROM "IntterraNearRealTimeUnitReflexes300sForeign" x WHERE x."IncidentDateTime" >= '05/01/2016' GROUP BY x."IncidentTypeCode" ORDER BY 1; 通常のテーブルで同じクエリを実行すると、.6秒で戻ります。実行計画はまったく異なります。 通常のテーブル Sort (cost=226861.20..226861.21 rows=4 width=4) (actual time=646.447..646.448 rows=7 loops=1) Sort Key: "IncidentTypeCode" Sort Method: quicksort Memory: 25kB -> HashAggregate (cost=226861.12..226861.16 rows=4 width=4) (actual time=646.433..646.434 rows=7 loops=1) Group Key: "IncidentTypeCode" -> Bitmap Heap …

12 postgresql  query-performance  postgresql-9.5  postgresql-fdw 

衛星データからの2つの地球測定値セットがあり、それぞれに時間フィールド（平均ユリウス日付のmjd）と地理的位置（GeoPoint、空間）があり、2つのセット間の一致が時間のしきい値に一致するように探しています3時間（または.125日）およびそれらの距離は互いに200 km以内です。 テーブルと空間テーブルの両方のmjdフィールドにインデックスを作成しました。 時間の制約に参加するだけで、データベースは8秒で100,000回の一致を計算し、その時間内のすべての100,000回の一致の距離を計算します。クエリは次のようになります。 select top 100000 h.Time, m.Time, h.GeoPoint.STDistance(m.GeoPoint)/1000.0 from L2V5.dbo.header h join L2.dbo.MLS_Header m on h.mjd between m.mjd-.125 and m.mjd+.125 option( table hint ( h, index(ix_MJD) ), table hint( m, index(ix_MJD) ) ) 実行された計画は次のとおりです。 並べ替えると、9つの距離が200km未満であったため、一致します。問題は、距離制約を追加して代わりにこれを実行すると、 select top 10 h.Time, m.Time, h.GeoPoint.STDistance(m.GeoPoint)/1000.0 from L2V5.dbo.header h join L2.dbo.MLS_Header m on …

12 sql-server  index  query-performance  join  spatial 

現在、一意のStoreKey/ProductKey組み合わせを含む2つのデータセットを比較しています。 1番目のデータセットには、StoreKey/ProductKey2012年1月から2014年5月の終わりまでの販売の一意の組み合わせがあります（結果= 45万行）。2番目のデータセットには、StoreKey/ProductKey2014年6月から今日までの販売の一意の組み合わせがあります（結果= 19万行）。 私はStoreKey/ProductKey、2番目のセットにはあるが、1番目のセットにはない組み合わせ、つまり6月初旬から販売された新製品を探しています。 これまで、2つのデータセットを一時テーブルにダンプし、両方のキーで両方のテーブルのインデックスを作成し、EXCEPTステートメントを使用して一意のアイテムを見つけました。 このような大きなデータセットを比較する最も効率的な方法は何ですか？このタイプの大規模な比較を行うより効率的な方法はありますか？

12 sql-server  sql-server-2008-r2  query-performance  except 

Sharepointサイトのトラブルシューティングに関する以前の質問のフォローアップとして、CXPACKETの待機について何かできるかどうか疑問に思いました。 ひざまずく解決策は、MAXDOPを1に設定することですべての並列処理をオフにすることであることを知っています。これは悪い考えのように聞こえます。しかし、別のアイデアは、並列処理が開始される前にコストのしきい値を増やすことです。実行計画のコストのデフォルトの5はかなり低いです。 だから私は、実行計画コストが最も高いクエリを見つけるクエリがすでに書かれているのだろうかと思っていました（実行期間などが最も長いクエリを見つけることができることを知っていますが、実行プランのコストはどこかで取得可能です、また、そのようなクエリが並行して実行されたかどうかも教えてくれます。 誰かがそのようなスクリプトを手元に持っていますか、またはこれを見つけるために関連するDMV、DMFまたは他のシステムカタログビューの方向に私を向けることができますか？

12 sql-server-2008  query-performance  performance-tuning  parallelism 

GROUP BY句を使用しない場合よりも、句を使用した場合に集計クエリの方がはるかに高速に実行される理由を知りたいのです。 たとえば、このクエリの実行には約10秒かかります SELECT MIN(CreatedDate) FROM MyTable WHERE SomeIndexedValue = 1 これは1秒もかかりませんが SELECT MIN(CreatedDate) FROM MyTable WHERE SomeIndexedValue = 1 GROUP BY CreatedDate CreatedDateこの場合は1つしかないため、グループ化されたクエリは、グループ化されていないクエリと同じ結果を返します。 2つのクエリの実行プランが異なることに気付きました-2番目のクエリは並列処理を使用しますが、最初のクエリは使用しません。 GROUP BY句がない場合、SQLサーバーが集計クエリを異なる方法で評価するのは正常ですか？また、GROUP BY句を使用せずに最初のクエリのパフォーマンスを改善するためにできることはありますか？ 編集 OPTION(querytraceon 8649)並列処理のコストオーバーヘッドを0に設定するために使用できることを学びました。これにより、クエリで並列処理が使用され、ランタイムが2秒に短縮されます。 SELECT MIN(CreatedDate) FROM MyTable WHERE SomeIndexedValue = 1 OPTION(querytraceon 8649) クエリはユーザーの選択時に値を入力することを目的としているため、実行時間を短くしたいので、グループ化されたクエリのように瞬時に実行するのが理想的です。今はクエリをラップしていますが、それが理想的なソリューションではないことはわかっています。 SELECT Min(CreatedDate) FROM ( SELECT Min(CreatedDate) as CreatedDate …

12 sql-server-2005  query-performance  aggregate  parallelism 

SQL Server 2012では800ミリ秒で実行され、SQL Server 2014では約170秒かかるクエリがあります。これを、Row Count Spool演算子のカーディナリティーの見積もりが悪いものに絞り込んだと思います。スプールオペレーターについて少し読んだことがありますが（例：こことここ）、まだいくつかのことを理解できません。 このクエリにRow Count Spool演算子が必要なのはなぜですか？正確さのために必要だとは思わないので、具体的にどのような最適化を提供しようとしているのですか？ SQL ServerがRow Count Spool演算子への結合がすべての行を削除すると推定するのはなぜですか？ これはSQL Server 2014のバグですか？もしそうなら、私はConnectにファイルします。しかし、私は最初により深い理解をお願いします。 注：LEFT JOINSQL Server 2012とSQL Server 2014の両方で許容可能なパフォーマンスを実現するために、クエリをとして書き換えるか、テーブルにインデックスを追加できます。この質問は、この特定のクエリを理解し、詳細に計画することに関するもので、詳細については説明しません。クエリの言い方を変えるには 遅いクエリ 完全なテストスクリプトについては、このPastebinを参照してください。これが私が見ている特定のテストクエリです： -- Prune any existing customers from the set of potential new customers -- This query is much slower than expected in SQL Server 2014 SELECT …

12 sql-server  query-performance  sql-server-2014  cardinality-estimates 

巨大な本番データベースがあり、そのサイズは約300GBです。削除クエリのパフォーマンスを向上させる方法はありますか？現在、削除速度は1分あたり1〜10kですが、非常に低速です。

12 sql-server  query-performance