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

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

2
個別選択を高速化する方法は?
私はいくつかの時系列データで単純な選択を区別しています: SELECT DISTINCT user_id FROM events WHERE project_id = 6 AND time > '2015-01-11 8:00:00' AND time < '2015-02-10 8:00:00'; そして、それは112秒かかります。クエリプランは次のとおりです。 http://explain.depesz.com/s/NTyA 私のアプリケーションは、多くの異なる操作を実行する必要があり、このようにカウントします。この種のデータを取得するより速い方法はありますか?

1
オペレーターがtempdbを使用して、実行中に流出レベル2でデータを流出させました
警告Operator usedtempdbを使用して、クエリプランでの並べ替え操作のコストを最小限に抑えるのに苦労していますto spill data during execution with spill level 2 流出レベル1で実行中に流出データに関連するいくつかの投稿を見つけましたが、レベル2ではありません。レベル1は古い統計に起因しているようですが、レベル2はどうですか?に関連するものは見つかりませんでしたlevel 2。 この記事はソート警告に関連して非常に興味深いものでした。 SQL Serverで並べ替え警告を無視しない 私のSQLサーバー? Microsoft SQL Server 2014(SP2)(KB3171021)-12.0.5000.0(X64)2016年6月17日19:14:09 Copyright(c)Microsoft Corporation Enterprise Edition(64ビット)on Windows NT 6.3(Build 9600:)(Hypervisor) 私のハードウェア? ハーウェアを見つけるために以下のクエリを実行します: -SQL Server 2012のハードウェア情報 SELECT cpu_count AS [Logical CPU Count], hyperthread_ratio AS [Hyperthread Ratio], cpu_count/hyperthread_ratio AS [Physical CPU Count], physical_memory_kb/1024 AS …

3
パフォーマンスを低下させるKey Lookup(クラスター化)オペレーターを排除
実行計画でキー検索(クラスター化)演算子を削除するにはどうすればよいですか? テーブルにはtblQuotes既にクラスター化インデックス(QuoteID)と27個の非クラスター化インデックスがあるため、これ以上作成しないようにしています。 私QuoteIDはクエリにクラスター化インデックス列を入れて、それが役立つことを願っていますが、残念ながらまだ同じです。 実行計画はこちら。 またはそれを見る: これは、キールックアップオペレーターによるものです。 クエリ: declare @EffDateFrom datetime ='2017-02-01', @EffDateTo datetime ='2017-08-28' SET NOCOUNT ON SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED IF OBJECT_ID('tempdb..#Data') IS NOT NULL DROP TABLE #Data CREATE TABLE #Data ( QuoteID int NOT NULL, --clustered index [EffectiveDate] [datetime] NULL, --not indexed [Submitted] [int] NULL, [Quoted] …

1
SQL Server-ストアドプロシージャとプランキャッシュのIfロジック
SQL Server 2012および2016 Standard: if-elseパラメータの値に応じて、コードの2つのブランチのいずれかを実行するためにロジックをストアドプロシージャに配置すると、エンジンは最新バージョンをキャッシュしますか? また、次の実行時にパラメーターの値が変更された場合、コードの別のブランチを実行する必要があるため、ストアドプロシージャを再コンパイルおよび再キャッシュしますか?(このクエリはコンパイルに非常にコストがかかります。)

1
日付の比較を行うサブクエリのパフォーマンスが悪い
サブクエリを使用して、一致するフィールドを持つすべての以前のレコードの合計数を検索する場合、5万件のレコードがあるテーブルでパフォーマンスはひどいです。サブクエリがなければ、クエリは数ミリ秒で実行されます。サブクエリを使用すると、実行時間は1分以上になります。 このクエリの場合、結果は次のようになります。 特定の日付範囲内のレコードのみを含めます。 日付範囲に関係なく、現在のレコードを含まない、以前のすべてのレコードのカウントを含めます。 基本的なテーブルスキーマ Activity ====================== Id int Identifier Address varchar(25) ActionDate datetime2 Process varchar(50) -- 7 other columns サンプルデータ Id Address ActionDate (Time part excluded for simplicity) =========================== 99 000 2017-05-30 98 111 2017-05-30 97 000 2017-05-29 96 000 2017-05-28 95 111 2017-05-19 94 222 2017-05-30 推測される結果 日付範囲のため2017-05-29に2017-05-30 …

2
300,000行のテーブルで実行するのに11分かかるクエリを結合します
以下のクエリの実行には11分以上かかります。 SELECT `c`.*, `e`.`name` AS `employee_name`, `e`.`emp_no`, `d`.`code` AS `department_code`, IF(ew.code IS NOT NULL, ew.code, egw.code) AS shift_code, IF(ew.code IS NOT NULL, ew.time_in_from, egw.time_in_from) AS time_in_from, IF(ew.code IS NOT NULL, ew.time_out_to, egw.time_out_to) AS time_out_to, IF(ew.code IS NOT NULL, ew.next_day, egw.next_day) AS next_day FROM `tms_emp_badge_card` AS `c` LEFT JOIN `tms_door_record_raw` AS …

3
EXISTSクエリがインデックスシークの代わりにインデックススキャンを行うのはなぜですか?
いくつかのクエリの最適化に取り組んでいます。 以下のクエリの場合、 SET STATISTICS IO ON; DECLARE @OrderStartDate DATETIME2 = '27 feb 2016'; DECLARE @OrderEndDate DATETIME2 = '28 feb 2016'; SELECT o.strBxOrderNo , o.sintOrderStatusID , o.sintOrderChannelID , o.sintOrderTypeID , o.sdtmOrdCreated , o.sintMarketID , o.strOrderKey , o.strOfferCode , o.strCurrencyCode , o.decBCShipFullPrice , o.decBCShipFinal , o.decBCShipTax , o.decBCTotalAmount , o.decWrittenTotalAmount , o.decBCWrittenTotalAmount …

1
sp_cursoropenと並列処理
私は頭を悩ませることができないように見えるクエリでパフォーマンスの問題に直面しています。 カーソル定義からクエリを引き出しました。 このクエリの実行には数秒かかります SELECT A.JOBTYPE FROM PRODROUTEJOB A WHERE ((A.DATAAREAID=N'IW') AND ((A.CALCTIMEHOURS<>0) AND (A.JOBTYPE<>3))) AND EXISTS (SELECT 'X' FROM PRODROUTE B WHERE ((B.DATAAREAID=N'IW') AND (((((B.PRODID=A.PRODID) AND ((B.PROPERTYID=N'PR1526157') OR (B.PRODID=N'PR1526157'))) AND (B.OPRNUM=A.OPRNUM)) AND (B.OPRPRIORITY=A.OPRPRIORITY)) AND (B.OPRID=N'GRIJZEN'))) AND NOT EXISTS (SELECT 'X' FROM ADUSHOPFLOORROUTE C WHERE ((C.DATAAREAID=N'IW') AND ((((((C.WRKCTRID=A.WRKCTRID) AND (C.PRODID=B.PRODID)) AND …

3
WHERE条件とGROUP BYを使用したSQLクエリのインデックス
WHERE条件付きのSQLクエリに使用するインデックスと、GROUP BY現在非常に遅いインデックスを決定しようとしています。 私のクエリ: SELECT group_id FROM counter WHERE ts between timestamp '2014-03-02 00:00:00.0' and timestamp '2014-03-05 12:00:00.0' GROUP BY group_id テーブルには現在32.000.000行があります。時間枠を増やすと、クエリの実行時間が非常に長くなります。 問題のテーブルは次のようになります。 CREATE TABLE counter ( id bigserial PRIMARY KEY , ts timestamp NOT NULL , group_id bigint NOT NULL ); 現在、次のインデックスがありますが、パフォーマンスはまだ遅いです。 CREATE INDEX ts_index ON counter USING btree (ts); …

1
SQL Serverは、述語が相関していることをどのように知っていますか?
:診断しながら、SQL Server 2008 R2のが悪いカーディナリティ推定(シンプルインデックスにもかかわらず、最新の統計情報など)ので、貧弱なクエリ計画を照会し、私はおそらく関連のKBの記事見つけ クエリを実行するとパフォーマンスの低下:FIXをSQL Server 2008またはSQL Server 2008 R2またはSQL Server 2012の相関AND述語を含む KB記事の意味は「相関」によって推測できます。たとえば、述語#2と述語#1は、主に同じ行を対象としています。 しかし、SQL Serverがこれらの相関関係をどのように認識しているかはわかりません。テーブルには、両方の述語の列を含む複数列のインデックスが必要ですか?SQLは統計を使用して、ある列の値が別の列と相関しているかどうかを確認しますか?または、他の方法が使用されていますか? 私はこれを2つの理由で尋ねています: この修正プログラムを使用してどのテーブルとクエリが改善される可能性があるかを判断するには #1に影響を与えるためにインデックス作成、統計などで何をすべきかを知るため

2
1秒未満で発生するブロッキングを追跡する方法-SQL Server
1秒未満で発生するブロッキングの問題をトラブルシューティングしようとしています。OLTPアプリケーションは非常に機密性が高く、合意されたSLAに従って一部のトランザクションの応答時間が200ミリ秒未満である必要があります。新しいコードリリースにはロックエスカレーションの問題がいくつかあり、更新プログラムのバッチサイズを小さくすることで解決できました。バッチサイズが小さい場合でも、新しいspがOLTPトランザクションが更新しているのと同じ行をブロックしていると思われます。 ブロックされているセッションと待機しているリソースを見つける必要があります。私の理解では、「ブロックされたプロセスのしきい値」は最低1秒に設定できるため、ブロックはキャプチャされません。 wait_infoイベントとwait_completed xイベントを試しています。 これを追跡できる他の方法はありますか。ありがとう

2
PostgreSQL TRIGGERのスケーリング
Postgresがメカニズムのスケールをトリガーする方法 PostgreSQLを大規模にインストールしており、ログテーブルとTRIGGERを使用してイベントベースのシステムを実装しようとしています。 基本的に、UPDATE / INSERT / DELETE操作の通知を受け取る各テーブルにTRIGGERを作成します。このトリガーが起動されると、ログテーブルに新しい行を追加する(イベントをエンコードする)関数を実行し、その後、外部サービスからポーリングします。 Postgres TRIGGERを使用する前に、それらがどのようにスケーリングするかを知りたいと思います。単一のPostgresインストールでいくつのトリガーを作成できますか?クエリのパフォーマンスに影響しますか?これを試す前に誰かがしましたか?

1
避けるべきではありませんか?
一部のSQL Server開発者の間でNOT INは、非常に遅いと広く信じられている信念であり、クエリは、同じ結果を返すが「悪」キーワードを使用しないように書き換える必要があります。(例)。 それに真実はありますか? 例えば、使用してクエリの原因となるSQL Serverのいくつかの既知のバグ(バージョンは?)ありますNOT IN使用している同等のクエリよりも悪い実行計画を持っています LEFT JOIN組み合わせNULL小切手または (SELECT COUNT(*) ...) = 0中WHERE節?

3
IN()を使用してクエリのパフォーマンスを改善する
次のSQLクエリがあります。 SELECT Event.ID, Event.IATA, Device.Name, EventType.Description, Event.Data1, Event.Data2 Event.PLCTimeStamp, Event.EventTypeID FROM Event INNER JOIN EventType ON EventType.ID = Event.EventTypeID INNER JOIN Device ON Device.ID = Event.DeviceID WHERE Event.EventTypeID IN (3, 30, 40, 41, 42, 46, 49, 50) AND Event.PLCTimeStamp BETWEEN '2011-01-28' AND '2011-01-29' AND Event.IATA LIKE '%0005836217%' ORDER BY Event.ID; …

4
数百万行の狭いテーブルでクエリのパフォーマンスを向上させることは可能ですか?
現在、クエリの完了に平均2500msかかっています。私のテーブルは非常に狭いですが、4,400万行あります。パフォーマンスを改善するためにどのようなオプションが必要ですか、またはこれは得られるほど良いですか? クエリ SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; テーブル CREATE TABLE [dbo].[Heartbeats]( [ID] [int] IDENTITY(1,1) NOT NULL, [DeviceID] [int] NOT NULL, [IsPUp] [bit] NOT NULL, [IsWebUp] [bit] NOT NULL, [IsPingUp] [bit] NOT NULL, [DateEntered] [datetime] NOT NULL, CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED ( [ID] …

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