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

[挨拶] （チェックしてください） [ ] Well trained professional, [ ] Casual reader, [ ] Hapless wanderer, 私は持っています（該当するものすべてをチェックしてください） [ ] query [ ] stored procedure [ ] database thing maybe 正常に実行されていた（該当する場合） [ ] yesterday [ ] in recent memory [ ] at some point しかし、今は突然遅くなっています。 既にブロックされていないこと、および長期にわたるメンテナンスタスク、レポート、またはその他の帯域外プロセスの犠牲になっていないことを確認しました。 問題は何ですか、どうすればよいですか、また、ヘルプを得るためにどのような情報を提供できますか？ [*Insert appropriate closing remarks*]

76 sql-server  query-performance  execution-plan  parameter-sniffing 

PostgreSQLの最新バージョン（2013年12月現在）では、パフォーマンスを向上させるために2つ以上のコア間でクエリを共有できますか？または、より高速なコアを取得する必要がありますか？

57 postgresql  query-performance  parallelism 

日付範囲でローリングサムを計算する必要があります。説明するために、AdventureWorksサンプルデータベースを使用して、次の仮想構文で必要なことを正確に実行できます。 SELECT TH.ProductID, TH.TransactionDate, TH.ActualCost, RollingSum45 = SUM(TH.ActualCost) OVER ( PARTITION BY TH.ProductID ORDER BY TH.TransactionDate RANGE BETWEEN INTERVAL 45 DAY PRECEDING AND CURRENT ROW) FROM Production.TransactionHistory AS TH ORDER BY TH.ProductID, TH.TransactionDate, TH.ReferenceOrderID; 悲しいことに、RANGEウィンドウフレーム範囲は現在SQL Serverで間隔を許可していません。 サブクエリと通常の（非ウィンドウ）集計を使用してソリューションを作成できることを知っています。 SELECT TH.ProductID, TH.TransactionDate, TH.ActualCost, RollingSum45 = ( SELECT SUM(TH2.ActualCost) FROM Production.TransactionHistory AS TH2 …

56 sql-server  sql-server-2012  query-performance  t-sql  window-functions 

非常に一般的なクエリパターンがありますが、効率的なクエリを作成する方法がわかりません。別のテーブルの行の「後ではなく最新の日付」に対応するテーブルの行を検索したい。 inventoryたとえば、特定の日に保有する在庫を表すテーブルがあります。 date | good | quantity ------------------------------ 2013-08-09 | egg | 5 2013-08-09 | pear | 7 2013-08-02 | egg | 1 2013-08-02 | pear | 2 そして、「価格」と言うテーブルは、特定の日に財の価格を保持します date | good | price -------------------------- 2013-08-07 | egg | 120 2013-08-06 | pear | 200 2013-08-01 | egg | 110 …

53 postgresql  query-performance  postgresql-performance  greatest-n-per-group 

このようなKimberly TrippによるSQL Serverプランのキャッシュに関するいくつかの素晴らしい記事を読んでいます：http : //www.sqlskills.com/blogs/kimberly/plan-cache-and-optimizing-for-adhoc-workloads/ 「アドホックワークロード向けに最適化する」オプションさえあるのはなぜですか？これは常にオンにすべきではありませんか？開発者がアドホックSQLを使用しているかどうかに関係なく、それをサポートするすべてのインスタンス（SQL 2008+）でこのオプションを有効にしないのはなぜですか？

49 sql-server  performance  query-performance  memory  cache 

私はかなり単純なクエリを持っています SELECT TOP 1 dc.DOCUMENT_ID, dc.COPIES, dc.REQUESTOR, dc.D_ID, cj.FILE_NUMBER FROM DOCUMENT_QUEUE dc JOIN CORRESPONDENCE_JOURNAL cj ON dc.DOCUMENT_ID = cj.DOCUMENT_ID WHERE dc.QUEUE_DATE <= GETDATE() AND dc.PRINT_LOCATION = 2 ORDER BY cj.FILE_NUMBER それは私に恐ろしいパフォーマンスを与えています（それが終わるのを待つことを決して気にしないような）クエリプランは次のようになります。 しかし、削除するTOP 1と、次のような計画が得られ、1〜2秒で実行されます。 以下のPKとインデックスの修正。 TOP 1クエリプランが変更されたからといって驚くことはありませんが、それによって事態がさら​​に悪化していることに少し驚いています。 注：この投稿の結果を読んで、a Row Goalなどの概念を理解しています。私が興味を持っているのは、より良いプランを使用するようにクエリを変更する方法です。現在、データを一時テーブルにダンプしてから、最初の行を取り出しています。より良い方法があるかどうか疑問に思っています。 編集事実の後にこれを読んでいる人々のために、ここにいくつかの追加情報があります。 Document_Queue-PK / CIはD_IDであり、〜5k行があります。 Correspondence_Journal-PK / CIはFILE_NUMBER、CORRESPONDENCE_IDで、行数は約140万です。 私が始めたとき、他のインデックスはありませんでした。私はCorrespondence_Journal（Document_Id、File_Number）で1つになりました

39 sql-server  sql-server-2008-r2  query-performance  performance-tuning 

UAT（3秒で実行）とPROD（23秒で実行）で同じクエリを実行すると、なぜこんなに大きな違いがあるのか​​を理解したいと思います。 UATとPRODの両方に、正確なデータとインデックスがあります。 クエリ： set statistics io on; set statistics time on; SELECT CONF_NO, 'DE', 'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance', CONF_TARGET_NO FROM CONF_TARGET ct WHERE CONF_NO = 161 AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-' AND ( ( REGISTRATION_TYPE = 'I' AND (SELECT COUNT(1) FROM PORTFOLIO WHERE EMAIL_ADDRESS …

39 sql-server-2008-r2  query-performance 

16 GBのRAMを搭載した8コアのRHEL 6.3で実行されているPostgreSQL 9.2インスタンスがあります。サーバーはこのデータベース専用です。デフォルトのpostgresql.confはメモリ設定に関してかなり保守的であるため、Postgresがより多くのメモリを使用できるようにすることは良い考えだと思いました。驚いたことに、wiki.postgresql.org / wiki / Tuning_Your_PostgreSQL_Serverのアドバイスに従うと、実際に実行するすべてのクエリが大幅に遅くなりましたが、より複雑なクエリでは明らかに目立ちます。 pgtuneの実行も試してみました。これは、調整されたパラメーターを増やして次の推奨事項を提示しましたが、何も変わりませんでした。RAMサイズの1/4のshared_buffersが推奨されますが、これは他のアドバイス（特にPG wiki）に沿っているようです。 default_statistics_target = 50 maintenance_work_mem = 960MB constraint_exclusion = on checkpoint_completion_target = 0.9 effective_cache_size = 11GB work_mem = 96MB wal_buffers = 8MB checkpoint_segments = 16 shared_buffers = 3840MB max_connections = 80 設定を変更した後（を使用してreindex database）データベース全体のインデックスを再作成しようとしましたが、それも役に立ちませんでした。shared_buffersとwork_memをいじりました。非常に控えめなデフォルト値（128k / 1MB）から徐々に変更すると、パフォーマンスが徐々に低下します。 私は走ったEXPLAIN (ANALYZE,BUFFERS)いくつかのクエリにし、犯人はハッシュが大幅に遅くなりましょうということのようです。理由は明らかではありません。 特定の例を挙げると、次のクエリがあります。デフォルト構成で約2100ミリ秒、バッファーサイズを増やした構成で約3300ミリ秒で実行されます。 select count(*) from …

39 postgresql  query-performance 

私たちのシステムは大量のデータを書き込みます（ビッグデータシステムの一種）。書き込みパフォーマンスはニーズには十分ですが、読み取りパフォーマンスは本当に遅すぎます。 主キー（制約）構造は、すべてのテーブルで類似しています： timestamp(Timestamp) ; index(smallint) ; key(integer). テーブルには数百万行、さらには数十億行あり、通常、読み取り要求は特定の期間（タイムスタンプ/インデックス）とタグに対して行われます。通常、約20万行を返すクエリがあります。現在、1秒あたり約15,000行を読み取ることができますが、10倍高速にする必要があります。これは可能ですか？もし可能なら、どのように？ 注： PostgreSQLはソフトウェアにパッケージ化されているため、ハードウェアはクライアントごとに異なります。 これは、テストに使用されるVMです。VMのホストは、24.0 GBのRAMを備えたWindows Server 2008 R2 x64です。 サーバー仕様（仮想マシンVMWare） Server 2008 R2 x64 2.00 GB of memory Intel Xeon W3520 @ 2.67GHz (2 cores) postgresql.conf 最適化 shared_buffers = 512MB (default: 32MB) effective_cache_size = 1024MB (default: 128MB) checkpoint_segment = 32 (default: 3) checkpoint_completion_target …

39 postgresql  query-performance  postgresql-9.1 

最適化しようとしている中程度に複雑なクエリのTOP n場合、句を削除すると実行プランが変更されることに気付きました。クエリにTOP nデータベースエンジンが含まれている場合、TOP句を無視してクエリを実行し、最後にその結果セットを要求されたn行まで縮小するだけだと思いました。グラフィカルな実行計画は、これが事実であることを示しているようです- TOP「最後の」ステップです。しかし、さらに進んでいるようです。 私の質問は、TOP n句がクエリの実行計画にどのように（そしてなぜ）影響するかです。 これは私の場合に起こっていることの単純化されたバージョンです： クエリは、AとBの2つのテーブルの行を照合しています。 TOP句がない場合、オプティマイザは、テーブルAから19k行、テーブルBから46k行があると推定します。返される実際の行数は、Aで16k、Bで13kです。合計69行（ソートが適用されます）。このクエリは非常に高速に発生します。 TOP 1001オプティマイザーを追加するとき、ハッシュ一致を使用しません。代わりに、最初にテーブルAからの結果をソートし（同じ推定値/実際の19k / 16k）、テーブルBに対してネストされたループを実行します。テーブルBの推定行数は1になり、奇妙なことはTOP n、 Bに対する推定実行数（インデックスシーク）-常に2n + 1、または私の場合は2003であるように見えますTOP n。もちろん、これはネストされた結合であるため、実際の実行回数は16k（テーブルAの行数）であり、これによりクエリの速度が低下します。 実際のシナリオはもう少し複雑ですが、これは基本的なアイデア/動作をキャプチャします。両方のテーブルは、インデックスシークを使用して検索されます。これはSQL Server 2008 R2 Enterpriseエディションです。

35 sql-server  query-performance  execution-plan  optimization 

クエリ内の未使用のCTEはパフォーマンスに影響し、生成されたクエリプランを変更しますか？

32 sql-server  query-performance  execution-plan  cte 

SQL Serverは、クエリプランの推奨されないインデックスのキー列の順序をどのように決定しますか？

32 sql-server  query-performance  index-tuning 

問題： 互換性またはマッチングについて、メンバーがお互いに評価できるソーシャルサイトがあります。このuser_match_ratingsテーブルには、2億2000万を超える行（9ギガのデータまたはほぼ20ギガのインデックス）が含まれています。このテーブルに対するクエリは、slow.log（しきい値> 2秒）に定期的に表示され、システムで最も頻繁に記録される低速クエリです。 Query_time: 3 Lock_time: 0 Rows_sent: 3 Rows_examined: 1051 "select rating, count(*) as tally from user_match_ratings where rated_user_id = 395357 group by rating;" Query_time: 4 Lock_time: 0 Rows_sent: 3 Rows_examined: 1294 "select rating, count(*) as tally from user_match_ratings where rated_user_id = 4182969 group by rating;" Query_time: 3 Lock_time: …

31 mysql  query-performance 

UPDATE実際にデータを変更しないステートメントがある場合（データは既に更新された状態にあるため）。WHERE更新を防ぐために節にチェックを入れることでパフォーマンス上の利点はありますか？ たとえば、次のUPDATE 1とUPDATE 2の実行速度に違いがあります。 CREATE TABLE MyTable (ID int PRIMARY KEY, Value int); INSERT INTO MyTable (ID, Value) VALUES (1, 1), (2, 2), (3, 3); -- UPDATE 1 UPDATE MyTable SET Value = 2 WHERE ID = 2 AND Value <> 2; SELECT @@ROWCOUNT; -- UPDATE 2 UPDATE MyTable SET …

31 sql-server  query-performance  update 

予期しないものとして説明するクエリパフォーマンスの問題を再現することができました。内部に焦点を当てた答えを探しています。 私のマシンでは、次のクエリがクラスター化インデックススキャンを実行し、約6.8秒のCPU時間を消費します。 SELECT ID1, ID2 FROM two_col_key_test WITH (FORCESCAN) WHERE ID1 NOT IN ( N'1', N'2',N'3', N'4', N'5', N'6', N'7', N'8', N'9', N'10', N'11', N'12',N'13', N'14', N'15', N'16', N'17', N'18', N'19', N'20' ) AND (ID1 = N'FILLER TEXT' AND ID2 >= N'' OR (ID1 > N'FILLER TEXT')) ORDER BY ID1, …

30 sql-server  query-performance  database-internals