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

15の試験マークを保存する必要がある学生追跡プログラムを開発しています。 マークを文字列として保存し、算術演算の実行などの目的で、必要に応じて分割できます。しかし、私はできるだけ多くのパフォーマンスが必要です。 どちらが良いですか？単一の文字列フィールド、または15の個々のintフィールド？

9 database-design  query-performance  datatypes 

私はこれに似たデータベース構造を持っています、 CREATE TABLE [dbo].[Dispatch]( [DispatchId] [int] NOT NULL, [ContractId] [int] NOT NULL, [DispatchDescription] [nvarchar](50) NOT NULL, CONSTRAINT [PK_Dispatch] PRIMARY KEY CLUSTERED ( [DispatchId] ASC, [ContractId] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO CREATE TABLE …

9 sql-server  query-performance 

やや複雑なSQL Server 2008クエリ（約200行のかなり高密度のSQL）があり、必要なときに実行されませんでした。時間の経過とともに、パフォーマンスは約0.5秒から約2秒に低下しました。 実行計画を見ると、結合を並べ替えることでパフォーマンスが向上することは明らかでした。私はそうしました、そしてそれは...約0.3秒にまで減少しました。これで、クエリに「OPTION FORCE ORDER」というヒントが追加されました。 今日、私はデータベースをクリーンアップします。行の約20％をアーカイブし、行を削除する以外は関連するデータベースでアクションを実行しません...実行プランは完全にホースされます。特定のサブツリーが返す行数を完全に誤って判断し、（たとえば）次のものを置き換えます。 <Hash> と <NestedLoops Optimized='false' WithUnorderedPrefetch='true'> これで、クエリ時間が約0.3秒から約18秒に急上昇します。（！）行を削除したからといって。クエリヒントを削除すると、クエリ時間は約2秒に戻ります。良いが悪い。 データベースを複数の場所とサーバーに復元した後、問題を再現しました。各テーブルから行の約20％を削除するだけで、常にこの問題が発生します。 強制結合順序がクエリの見積もりを完全に不正確にする（したがってクエリの時間を予測できない）のは、これが正常ですか？ 最適ではないクエリのパフォーマンスを受け入れる必要があるか、それともタカのように見て、頻繁に手動でクエリのヒントを編集する必要があると思いますか？または、すべての結合についてもヒントがありますか？.3sから2sは大ヒットです。 行を削除した後にオプティマイザが停止した理由は明らかですか？たとえば、「はい、サンプルスキャンを実行しました。データ履歴の前半でほとんどの行をアーカイブしたため、サンプルはスパースな結果を生成したため、ソートされたハッシュ演算の必要性を過小評価していました」 実行計画を見たい場合は、投稿できる場所を提案してください。そうでなければ、私は最も素晴らしいビットをサンプリングしました。これが根本的な誤推定です。括弧内の数字は（推定：実際の）行です。 / Clustered Index Scan (908:7229) Nested Loops (Inner Join) --< \ NonClustered Index Seek (1:7229) 内部ループは908行をスキャンすると予想されますが、代わりに52,258,441をスキャンすることに注意してください。正確であれば、このブランチは12秒ではなく、約2ミリ秒で実行されたはずです。行を削除する前に、この内部結合の推定は合計係数2だけオフであり、2つのクラスター化インデックスのハッシュ一致として実行されました。

9 sql-server  sql-server-2008  query-performance  optimization  hints 

店舗からデータを取得し、会社全体の在庫表を更新するプロセスがあります。このテーブルには、日付別およびアイテム別のすべてのストアの行があります。多くの店舗を持つ顧客では、このテーブルは非常に大きくなる可能性があり、5億行程度になります。 この在庫更新プロセスは、通常、ストアがデータを入力するときに1日に何度も実行されます。これらの実行は、ほんの数店舗のデータを更新します。ただし、これを実行して、たとえば過去30日間のすべての店舗を更新することもできます。この場合、プロセスは10のスレッドを起動し、各ストアの在庫を別のスレッドで更新します。 お客様から、プロセスに時間がかかっているとの不満が寄せられています。プロセスのプロファイルを作成したところ、このテーブルにINSERTを実行する1つのクエリが予想以上に多くの時間を消費していることがわかりました。このINSERTは、30秒で完了する場合があります。 このテーブルに対してBEGIN TRANとROLLBACKで区切られたアドホックSQL INSERTコマンドを実行すると、アドホックSQLはミリ秒のオーダーで完了します。 パフォーマンスの遅いクエリは次のとおりです。アイデアは、そこにないレコードを挿入し、後でデータのさまざまなビットを計算するときにそれらを更新することです。プロセスの前のステップでは、更新する必要のあるアイテムを特定し、いくつかの計算を行い、結果をtempdbテーブルUpdate_Item_Workに詰め込みました。このプロセスは10個の個別のスレッドで実行されており、各スレッドはUpdate_Item_Workに独自のGUIDを持っています。 INSERT INTO Inventory ( Inv_Site_Key, Inv_Item_Key, Inv_Date, Inv_BusEnt_ID, Inv_End_WtAvg_Cost ) SELECT DISTINCT UpdItemWrk_Site_Key, UpdItemWrk_Item_Key, UpdItemWrk_Date, UpdItemWrk_BusEnt_ID, (CASE UpdItemWrk_Set_WtAvg_Cost WHEN 1 THEN UpdItemWrk_WtAvg_Cost ELSE 0 END) FROM tempdb..Update_Item_Work (NOLOCK) WHERE UpdItemWrk_GUID = @GUID AND NOT EXISTS -- Only insert for site/item/date combinations that don't …

9 sql-server  performance  query-performance 

ストアドプロシージャのパフォーマンスを改善しようとしています。SPを実行すると、何かがキャッシュされているかのように、ほぼ瞬時に終了します。SSMSでSPを実行する前に、次の2行のSQLを使用するように言われました。 DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE 上記の2行のコードでSPを実行すると、SPは約8秒で終了します。しかし、これは本当に私に本当の実行時間を与えていますか？どうやって知るの？

9 sql-server-2008  ssms  query-performance 

2つの非常によく似たクエリがあります 最初のクエリ： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' and a.TargetTypeId IN (1,2,3,4,5,6,7,8,9, 11,12,13,14,15,16,17,18,19, 21,22,23,24,25,26,27,28,29,30, 31,32,33,34,35,36,37,38,39, 41,42,43,44,45,46,47,48,49, 51,52,53,54,55,56,57,58,59, 61,62,63,64,65,66,67,68,69, 71,72,73,74,75,76,77,78,79) 結果：267479 計画：https : //www.brentozar.com/pastetheplan/?id=BJWTtILyS 2番目のクエリ： SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' …

9 sql-server  performance  query-performance  optimization  execution-plan 

2つのpg_trgmインデックスをテーブルに追加しました。これは、ユーザー名、またはサインアップ中にスペルが間違っているメールアドレス（ "@ gmail.con"など）でユーザーを検索する必要があるため、メールアドレスまたは名前によるあいまい検索を可能にします。ANALYZEインデックスの作成後に実行されました。 ただし、これらのインデックスのいずれかでランク付けされた検索を実行すると、ほとんどの場合非常に遅くなります。つまり、タイムアウトを長くすると、クエリが 60秒で返される場合がありますが、15秒という非常にまれな場合もありますが、通常はクエリがタイムアウトします。 pg_trgm.similarity_threshold0.3はのデフォルト値ですが、これを上げて0.8も違いはないようです。 この特定のテーブルには2,500万行以上があり、常に照会、更新、および挿入されます（それぞれの平均時間は2ミリ秒未満です）。セットアップは、汎用SSDストレージと多かれ少なかれデフォルトのパラメーターを備えたRDS db.m4.largeインスタンスで実行されているPostgreSQL 9.6.6です。pg_trgm拡張子はバージョン1.3です。 クエリ： SELECT * FROM users WHERE email % 'chris@example.com' ORDER BY email <-> 'chris@example.com' LIMIT 10; SELECT * FROM users WHERE (first_name || ' ' || last_name) % 'chris orr' ORDER BY (first_name || ' ' || last_name) <-> 'chris orr' …

9 postgresql  query-performance  postgresql-performance  postgresql-9.6 

.NET Core APIアプリを強化するAzure SQLデータベースがあります。Azure Portalでパフォーマンス概要レポートを参照すると、データベースサーバーの負荷（DTU使用量）の大部分がCPUからのものであり、具体的には1つのクエリが原因であることがわかります。 ご覧のように、クエリ3780は、サーバーのほぼすべてのCPU使用率の原因です。 クエリ3780（下記参照）は基本的にアプリケーションの核心であり、ユーザーから頻繁に呼び出されるため、これは多少意味があります。また、必要な適切なデータセットを取得するために必要な多くの結合を伴う、かなり複雑なクエリでもあります。クエリは、次のようなsprocから取得されます。 -- @UserId UNIQUEIDENTIFIER SELECT C.[Id], C.[UserId], C.[OrganizationId], C.[Type], C.[Data], C.[Attachments], C.[CreationDate], C.[RevisionDate], CASE WHEN @UserId IS NULL OR C.[Favorites] IS NULL OR JSON_VALUE(C.[Favorites], CONCAT('$."', @UserId, '"')) IS NULL THEN 0 ELSE 1 END [Favorite], CASE WHEN @UserId IS NULL OR C.[Folders] IS NULL …

9 sql-server  query-performance  execution-plan  azure-sql-database  cpu 

SQL Server 2016で導入された新しいクエリストアは素晴らしいです。これは、以前のプロファイラーツールで行っていた処理の多くを置き換えるのに最適です。ただし、リソースを大量に消費するクエリへの個々の呼び出しに関連するパラメータ値をキャプチャして、それを傍受する方法は見つかりませんでした。これは可能ですか？ Query Storeは個別の呼び出しよりも集計データを扱うことを理解しているので、ここでは運が悪いのではないかと思います。遅いクエリを見つけたとき、最も遅い呼び出しの1つに関連付けられたパラメータも持つとトラブルシューティングに便利です。最新の優れたツールを使用してこれを行う方法を知りたいのですが。（プロファイラーの使用をお見逃しなく！） セキュリティの観点から、Query Storeはプロファイラーよりもロックダウンされていますか？集計を計算するには、あるレベルで個々の呼び出しからデータをキャプチャする必要があると思います。それのいずれかが格納されているかどうかはわかりません。

9 sql-server  query-performance  sql-server-2016  query-store 

以下のこの質問の内容を自分の状況に適用しようとしていますが、可能であれば、演算子Hash Match（Inner Join）をどのようにして取り除くことができるのか、少し混乱しています。 SQL Serverクエリのパフォーマンス-ハッシュマッチ（内部結合）の必要性の排除 私は10％の費用に気づき、それを減らすことができるかどうか疑問に思っていました。以下のクエリプランを参照してください。 この作業は、今日調整しなければならなかったクエリサッドから来ています。 SELECT c.AccountCode, MIN(d.CustomerSID) FROM Stage.Customer c INNER JOIN Dimensions.Customer d ON c.Email = d.Email OR ( c.HomePostCode = d.HomePostCode AND c.StrSurname = d.strSurname ) GROUP BY c.AccountCode これらのインデックスを追加した後： --------------------------------------------------------------------- -- Create the indexes --------------------------------------------------------------------- CREATE NONCLUSTERED INDEX IDX_Stage_Customer_HOME_SURNAME_INCL ON Stage.Customer(HomePostCode ,strSurname) INCLUDE (AccountCode) …

9 sql-server  sql-server-2014  index  query-performance  execution-plan 

私はデータベースの初心者なので、このデータベースについてあなたの助けを求めています。 時系列データを含むテーブルがあります。 2012/01/01 00:10, 10 2012/01/01 00:30, 5 2012/01/01 01:00, 10 2012/01/01 01:40, 10 2012/01/01 02:00, 20 テーブルは、間隔の上限のみを維持することにより、間隔ベースのデータを格納しています。たとえば、最初の行は[00:00-00:10]からの間隔を10の値で表し、2番目の行は（00:10-00:30]からの間隔を5の値で表し、3番目の行は間隔は（00:30-01:00）で、値は10です。 上記のような構造の時間別データを集約するために、Postgresで効率的なクエリが必要です。したがって、結果は次のようになります。 2012/01/01 00:00, 2012/01/01 01:00, 25 2012/01/01 01:00, 2012/01/01 02:00, 30 時系列データは大きいので、これをインデックス付けする際の助けがあれば非常にありがたいです。 ありがとう、ダン

9 postgresql  query-performance  aggregate 

転換点の問題に最近遭遇し、クエリオプティマイザが検索列の非クラスタ化インデックスを単に無視するため、数秒以内に実行を完了するために使用されていた一部のレポートクエリが2分以上かかっています。以下のクエリの例： select top 100 * from [dbo].[t_Call] where ID > 0 and throwtime between '3/20/2014 7:00:00 AM' and '3/24/2014 6:59:59 AM' order by id ID列は、インデックスクラスタ化されたThrowtime非クラスタ化インデックスを持っています。この場合、クエリプランと非クラスター化インデックスthrowtimeをID変更するのではなく、順序付けを使用していることに気付きました。また、古いデータの一部をアーカイブすることも計画しています（現在、20 mln行あります!!）。しかし、アプリケーションでこれらの変更を行うにはしばらく時間がかかります。アプリケーションレベルで変更を加えずに、レポートを適度に高速に実行する方法を見つける必要があります（まあ、それは人生です）。 プランガイドを入力してください。非クラスター化インデックスのクエリヒントを使用して以下のプランガイドを作成しましたが、何らかの理由で、非クラスター化インデックスがまだ使用されていません。何か不足していますか？ EXEC sp_create_plan_guide @name = N'[prod2reports_callthrowtime]', @stmt = N'select top 100 * from [dbo] . [t_Call] where ID > @0 and @1 < = …

9 sql-server  query-performance  execution-plan  plan-guides 

データベースサーバーでのクエリの応答に時間がかかるようで、CPU使用率が高いと思います。を実行するとps aux、約250の「アイドル」接続が表示されます（多すぎると思われます）。私は完全な診断を始めていませんが、これが探し始めるのに良い場所かどうか知りたいと思っていました。 また、PgBouncerをトランザクションレベルのプールで使用しています。idleプールサイズを調整することで、接続数を簡単に減らすことができると思います。ただし、正当な理由がない限り、あまり多くの変更を開始したくありません。 idlePostgreSQL 9.2の多くの接続がパフォーマンスに影響を与える可能性はありますか？ どうもありがとう！

8 postgresql  database-design  performance  query-performance 

私は次のように4ノードAGセットアップを持っています。 すべてのノードのVMハードウェア構成： Microsoft SQL Server 2017 Enterprise Edition（RTM-CU14）（KB4484710） 16個のvCPU 356 GB RAM（これまでの話...） 最大並列度：1（アプリベンダーの要求に応じて） 並列処理のコストしきい値：50 最大サーバーメモリ（MB）：338944（331 GB） AG構成： ノード1：プライマリまたは同期コミット読み取り不可セカンダリ、自動フェイルオーバー用に構成 ノード2：プライマリまたは同期コミット、読み取り不可のセカンダリ、自動フェイルオーバー用に構成 ノード3：読み取り可能なセカンダリセット、非同期コミット、手動フェイルオーバー用に構成 ノード4：非同期のコミットを備えた読み取り可能なセカンダリセット、手動フェイルオーバー用に構成 問題のクエリ： このクエリについては、まったくおかしなことは何もありません。アプリケーション内のさまざまなキューにある未解決の作業項目の概要を提供します。以下の実行プランのリンクの1つからコードを確認できます。 プライマリノードでの実行動作： プライマリノードで実行した場合、実行時間は通常約1秒です。以下は実行計画です。以下は、プライマリノードからのSTATISTICS IOおよびSTATISTICS TIMEからキャプチャされた統計です。 (347 rows affected) Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical …

8 sql-server  performance  query-performance  availability-groups  sql-server-2017 

現在、トランザクションテーブルを設計しています。各行の現在までの合計を計算する必要があり、パフォーマンスが低下する可能性があることに気付きました。そこで、テスト用に100万行のテーブルを作成しました。 CREATE TABLE [dbo].[Table_1]( [seq] [int] IDENTITY(1,1) NOT NULL, [value] [bigint] NOT NULL, CONSTRAINT [PK_Table_1] PRIMARY KEY CLUSTERED ( [seq] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY] GO そして、最近の10行とその現在までの合計を取得しようとしましたが、約10秒かかりました。 --1st attempt SELECT TOP 10 seq …

8 sql-server  database-design  t-sql  query-performance  execution-plan