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

データベースクエリのパフォーマンスや効率の向上に関する質問。

1
シーク述語と述語の違い
SQL Server 2014 Enterpriseにあるクエリのパフォーマンスを調整しようとしています。 私はSQL Sentryのプランエクスプローラで、実際のクエリプランを開いていて、私はそれがいることを一つのノード上で見ることができる述語をシークしても述語 Seek PredicateとPredicateの違いは何ですか? 注:このノードには多くの問題(たとえば、推定行と実際の行、残りのIO)があることがわかりますが、質問はそれとは関係ありません。

2
DELETEクエリが別のフォーマットよりもはるかに長いフォーマットで実行されるのはなぜですか?
一部の重複を削除しようとする特定のクリーンアップコードがあります。 これは多くの顧客サイトで完全に実行されます。ログから、このクエリでは少なくとも1秒から45秒が消費されていることがわかります。 DELETE FROM [tbl] WHERE [Id] NOT IN ( SELECT MIN([Id]) FROM [tbl] GROUP BY [IdProject], [IdRepresentative], [TimeStart] ) しかし、私はこのクエリを4時間以上(現在までで、終了しない)実行している顧客がいます!私はDBをチェックしました(DBCC CHECKDB)、統計情報を更新しました(sp_updatestats)もUPDATE STATISTICS [tbl] WITH FULLSCAN変更を示していません。 お客様からDBの元のバックアップがあります。SQL Server 14.0.2002.14で実行しています。Standard Editionを持っていますが、お客様はExpress Editionを使用しています。 他の誰もDBを使用していないことをアクティビティモニターで確認できます。待機時間はなく、CPUは25%使用されています(4つのCPUのうちの1つのみ)。また、この私のテストケースでは、他の誰もDBを使用していません。 私はクエリを再構成し、このステートメントをチェックしました: DELETE FROM [tbl] FROM [tbl] AS t LEFT OUTER JOIN ( SELECT MIN([Id]) AS [IdMin] FROM [tbl] …

1
タイムスタンプでパーティション化されたテーブルを含む結合には、パーティション制約は使用されません
次のような分割テーブル構造があります。 CREATE TABLE measurements ( sensor_id bigint, tx timestamp, measurement int ); CREATE TABLE measurements_201201( CHECK (tx >= '2012-01-01 00:00:00'::timestamp without time zone AND tx < ('2012-01-01 00:00:00'::timestamp without time zone + '1 mon'::interval)) )INHERITS (measurements); CREATE INDEX ON measurements_201201(sensor_id); CREATE INDEX ON measurements_201201(tx); CREATE INDEX ON measurements_201201(sensor_id, tx); .... …

2
効率的な範囲集計クエリのためのデータベース?
簡単な例として、次のようなテーブルがあるとします。 seq | value ----+------ 102 | 11954 211 | 43292 278 | 19222 499 | 3843 テーブルには数億のレコードが含まれる可能性があり、次のようなクエリを頻繁に実行する必要があります。 SELECT sum(value) WHERE seq > $a and seq < $b seqインデックスが作成されている場合でも、一般的なデータベース実装は各行をループして、最良の場合の合計を計算します。O(n)ここnで、は範囲のサイズです。 O(log(n))クエリごとに、これを効率的に実行できるデータベースはありますか? ここで説明するように、セグメントツリーと呼ばれるデータ構造に遭遇しました。範囲ツリーまたは間隔ツリーとも呼ばれますが、これらの名前はすべて、データ構造のわずかに異なるバリエーションとして説明されることがよくあります。 しかし、そのようなデータ構造を実装するデータベースに出くわしたことはありません。インメモリ構造の場合、最初から実装するのは簡単ですが、永続化する必要がある場合や、メモリに収まりきらない場合は注意が必要です。これを既存のデータベースの上に実装するための効率的なパターンがある場合、それも役立ちます。 補足:これは追加専用のテーブルではないため、この場合、累積合計を保持するなどの解決策は機能しません。

2
SARGカーディナリティの推定、なぜフルスキャンではないのですか?
フルスキャンがないのはなぜですか(SQL 2008 R2および2012)。 テストデータ: DROP TABLE dbo.TestTable GO CREATE TABLE dbo.TestTable ( TestTableID INT IDENTITY PRIMARY KEY, VeryRandomText VarChar(50), VeryRandomText2 VarChar(50) ) Go Set NoCount ON Declare @i int Set @i = 0 While @i < 10000 Begin Insert Into dbo.TestTable(VeryRandomText, VeryRandomText2) Values(Cast(Rand()*10000000 as VarChar(50)), Cast(Rand()*10000000 as VarChar(50))); Set @i …

3
STIntersectsのパフォーマンスの向上
テーブルにT_PINは300,000のピンとT_POLYGON36,000のポリゴンがあります。T_PINこのインデックスがあります: CREATE SPATIAL INDEX [T_PIN_COORD] ON [dbo].[T_PIN] ( [Coord] )USING GEOGRAPHY_GRID WITH (GRIDS =(LEVEL_1 = HIGH,LEVEL_2 = HIGH,LEVEL_3 = HIGH,LEVEL_4 = HIGH), CELLS_PER_OBJECT = 128, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]; T_POLYGON 持っています: …

2
最長の接頭辞を見つけるアルゴリズム
テーブルが2つあります。 最初のものは接頭辞を持つテーブルです code name price 343 ek1 10 3435 nt 4 3432 ek2 2 2つ目は、電話番号を含む通話記録です number time 834353212 10 834321242 20 834312345 30 各レコードのプレフィックスから最長のプレフィックスを見つけるスクリプトを作成し、このすべてのデータを次のように3番目のテーブルに書き込む必要があります。 number code .... 834353212 3435 834321242 3432 834312345 343 番号834353212の場合、「8」をトリミングしてから、プレフィックステーブルから最長のコードである3435 を見つける必要があります。常に最初に「8」を削除し、プレフィックスを先頭に置く必要があります。 私は非常に悪い方法でずっと前にこの課題を解決しました。これは、各レコードに対して多くのクエリを実行する恐ろしいperlスクリプトでした。このスクリプト: 呼び出しテーブルから数値を取得し、ループ内でlength(number)から1 => $ prefixまでの部分文字列を実行します クエリを実行します: '$ prefix'のようなコードのプレフィックスからcount(*)を選択します count> 0の場合、最初のプレフィックスを取得してテーブルに書き込みます 最初の問題はクエリ数です- call_records * length(number)です。第二の問題はLIKE表現です。遅いと思います。 私は2番目の問題を解決しようとしました: …

3
インデックススキャンではなくPostgreSQL順次スキャンなぜですか?
こんにちは、私はPostgreSQLデータベースクエリに問題があり、誰かが手伝ってくれるかどうか疑問に思っています。いくつかのシナリオでは、私のクエリは、2つのテーブルdataとを結合するために使用した、私が作成したインデックスを無視しているようdata_areaです。これが発生すると、シーケンシャルスキャンが使用され、クエリが非常に遅くなります。 順次スキャン(〜5分) Unique (cost=15368261.82..15369053.96 rows=200 width=1942) (actual time=301266.832..301346.936 rows=153812 loops=1) CTE data -> Bitmap Heap Scan on data (cost=6086.77..610089.54 rows=321976 width=297) (actual time=26.286..197.625 rows=335130 loops=1) Recheck Cond: (datasetid = 1) Filter: ((readingdatetime >= '1920-01-01 00:00:00'::timestamp without time zone) AND (readingdatetime <= '2013-03-11 00:00:00'::timestamp without time zone) AND (depth >= 0::double …

3
RESTful APIのSQLデータベース構造
RESTful APIを作成しています。リソースを中心にデータベーステーブルを設計する最良の方法を決定するのに苦労しています。 最初は、リソースごとのテーブルが適していますが、これにより、リソースチェーンをさらに下っていくと、テーブルが指数的に大きくなるのではないかと心配しています。 たとえば、ユーザー、クライアント、販売の3つのリソースがあるとします。ユーザーは私のAPIのサブスクライバーであり、クライアントはユーザーの顧客であり、販売は各クライアントがユーザーアカウントに対して行った購入です。 次のように販売リソースにアクセスします GET /users/{userID}/clients/{clientID}/sales/{salesID} したがって、10人のユーザーがあり、それぞれに10人の顧客がいて、それぞれの顧客について10件の売上がある場合、テーブルサイズは、リソースチェーンを下に行くほど大きくなります。 SQLが大きなテーブルに対応できるとは確信していますが、読み取りと書き込みがどのように遅くなるかはわかりません。上の例はそれを説明していないかもしれませんが、私のAPIは次第に多くの書き込みと読み取りを行って、リソースチェーンのさらに下に行きます。したがって、データベース内の最大のテーブルが、小さいテーブルよりも多くの回数読み書きされるシナリオがあります。 クエリを実行する前にテーブルを結合する必要もあります。その理由は、各ユーザーが同じ名前のクライアントを持つことを許可するためです。間違ったクライアントデータを取得しないように、usersテーブルとclientsテーブルは{userID}によって結合されます。これは販売にも当てはまります。大きなテーブルを結合して読み取りと書き込みを実行すると、処理がさらに遅くなりますか?

4
SQLサーバーのCPU使用率が高い-クエリが遅い[終了]
この質問が今後の訪問者を助けることはほとんどありません。これは、地理的に狭い地域、特定の瞬間、またはインターネットの世界中のオーディエンスには一般的に適用できない非常に狭い状況にのみ関連しています。この質問をより広く適用するためのヘルプについては、ヘルプセンターにアクセスしてください。 6年前休業。 MS SQL Serverは、CPUパワーの約95%を使用しています。 サーバー(ハードウェア)の再起動後、またはSQLサービスの再起動後、使用率は0%で、1〜3日かけてゆっくりと増加します。使用量によって異なります。 80%を超えると、すべてのクエリが非常に遅くなります。 私たちのウェブサイトは多くの大きなクエリを扱っているので、それらのいくつかは45-60秒かかります。再起動後(CPU使用率が80%未満)、同じクエリで11〜20秒かかります。 どうすれば修正できますか?アフィニティマスクでCPU使用率を調整できることをオンラインで読みましたが、アフィニティ設定が無効になっています。変更できません。これはプロセッサが1つしかないためですか? クエリ自体にはたくさんのトリックがありますが、私たちのWebサイトとサービスは非常に大きく、変更するのは多すぎます。 それらのほとんどはすでにかなり最適化されています。 2秒しかかかりませんが、SQLサービスを再開し続けることができません。ユーザーが電話をかけてメッセージを録音できるアラームサービスがあるため、選択したグループが呼び出され、録音されたメッセージが聞こえます。 このシステムは何百人もの捜索救助チームによって使用されており、SQLサービスがアラーム中に再起動した場合、システムは終了し、呼び出した人には通知されません。 あちこち検索してみましたが、「アフィニティマスク」以外は変更できません。 現在のクエリを終了せずに、CPUキャッシュをクリアする方法が必要です... SQL: Microsoft SQL Server 11.0.2100.60 OS: Windows Server 2012 x64 Processor: 2.30 GHz RAM: 4.00 GB

1
結合とウィンドウ関数を使用してリード値とラグ値を取得するパフォーマンスの比較
私は20Mの行のテーブルを有し、各行は3つの列を有している:time、id、およびvalue。それぞれについてidとtime、そこにあるvalue状態のため。time特定の特定の特定のリードとラグの値を知りたいid。 これを達成するために2つの方法を使用しました。1つの方法は結合を使用し、もう1つの方法は、クラスター化インデックスがオンtimeおよびのウィンドウ関数lead / lagを使用することidです。 これら2つの方法のパフォーマンスを実行時間で比較しました。結合メソッドは16.3秒かかり、ウィンドウ関数メソッドは20秒かかります(インデックスの作成時間は含まれません)。結合メソッドがブルートフォースであるときにウィンドウ関数が進んでいるように見えるので、これは私を驚かせました。 2つのメソッドのコードは次のとおりです。 インデックスを作成 create clustered index id_time on tab1 (id,time) 結合方法 select a1.id,a1.time a1.value as value, b1.value as value_lag, c1.value as value_lead into tab2 from tab1 a1 left join tab1 b1 on a1.id = b1.id and a1.time-1= b1.time left join tab1 c1 on a1.id = c1.id …

3
1つのクエリで複数のカウントを行う方法は?
次のようなクエリでレコードを数えます SELECT COUNT(col1) FROM table1 WHERE col1 LIKE '%something%' SELECT COUNT(col1) FROM table1 WHERE col1 LIKE '%another%' SELECT COUNT(col1) FROM table1 WHERE col1 LIKE '%word%' カウントごとに、mysqlはテーブル全体をウォークスルーする必要があり、これは長いテーブルと多数のクエリがある場合の大きな問題です。 1つのクエリですべてのカウントを行う方法はあるのでしょうか。この場合、mysqlが各行をウォークスルーすると、すべてのカウントが処理されるため、テーブル全体を何度もスキャンする必要がありません。

1
SQL ServerがCTEを「最適化フェンス」として使用する場合に決定するルールは何ですか?
しばらく前に、Brent OzarがSQL ServerとPostgreSQLの違いのいくつかを詳しく説明した投稿を公開しました: SQL ServerとPostgreSQLの2つの重要な違い 最初のポイント(「CTEは最適化フェンス」)が私の目を引きました。提供されている例では、SQL ServerがCTEとメインクエリを組み合わせ、それを単一のクエリとして最適化している( PostgreSQL)。 ただし、この動作は、SQL ServerがCTEを最適化フェンスとして扱う他のブログやトレーニングクラスで見た例とは逆のようです。これにより、インデックスの使用やパフォーマンスの向上などが可能になります。次に例を示します。 星を選択するより良い方法 したがって、SQL ServerはCTEを最適化のフェンスとして「称賛」しているようです。SQL ServerがCTEを最適化フェンスとして確実に尊重する既知のケース(またはその逆の動作)の特定のリストを文書化する優れたリソースはありますか?

3
varchar(max)が原因で流出をtempdbにソート
32 GBのサーバーでは、最大メモリが25 GBのSQL Server 2014 SP2を実行しており、2つのテーブルがあります。ここでは、両方のテーブルの構造が簡略化されています。 CREATE TABLE [dbo].[Settings]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceId] [int] NULL, [typeID] [int] NULL, [remark] [varchar](max) NULL, CONSTRAINT [PK_Settings] PRIMARY KEY CLUSTERED ([id] ASC) ) ON [PRIMARY] GO CREATE TABLE [dbo].[Resources]( [id] [int] IDENTITY(1,1) NOT NULL, [resourceUID] [int] NULL, CONSTRAINT [PK_Resources] PRIMARY KEY CLUSTERED …

1
結合消去がsys.query_store_planで機能しないのはなぜですか?
以下は、クエリストアで発生するパフォーマンスの問題の簡略化です。 CREATE TABLE #tears ( plan_id bigint NOT NULL ); INSERT #tears (plan_id) VALUES (1); SELECT T.plan_id FROM #tears AS T LEFT JOIN sys.query_store_plan AS QSP ON QSP.plan_id = T.plan_id; plan_id列は、主キーとして文書化されているsys.query_store_planが、実行計画は使用されません撤廃への参加が期待されるように: DMVから投影される属性はありません。 DMV主キーplan_idは一時テーブルの行を複製できません A LEFT JOINが使用されているため、から行をT削除できません。 実行計画 これはなぜですか、ここで参加の削除を取得するにはどうすればよいですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.