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

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

2
バッチごとにコンパイルが発生します
T-SQLステートメントをバッチで送信するサードパーティアプリケーションがあります。 データベースは、SQL Server 2016 Enterprise SP1 CU7、16コア、256 GBメモリでホストされています。アドホックの最適化が有効になっています。 これは、実行されているクエリのダミーの例です。 exec sp_executesql N' IF @@TRANCOUNT = 0 SET TRANSACTION ISOLATION LEVEL SNAPSHOT select field1, field2 from table1 where field1=@1 option(keep plan, keepfixed, loop join) select field3, field4 from table2 where field3=@1 option(keep plan, keepfixed, loop join)', N'@1 nvarchar(6)',@1=N'test' データベースを監視し、毎秒のバッチ数と毎秒のコンパイル数を見ると、それらは常に同じであることがわかります。負荷が高い場合、これは1000バッチ/秒および1000コンパイル/秒になる可能性があります。平均負荷では、150バッチ/秒です。 最近コンパイルされたプランのクエリキャッシュを分析します。 SELECT …

1
2,135,044,521行テーブルのインデックスを最適化する
大きなテーブルでI / Oの問題があります。 一般的な統計 このテーブルには次の主な特徴があります。 環境:Azure SQLデータベース(階層はP4プレミアム(500 DTU)) 行:2,135,044,521 使用済みパーティション1,275 クラスター化およびパーティション化されたインデックス 型番 これはテーブルの実装です: CREATE TABLE [data].[DemoUnitData]( [UnitID] [bigint] NOT NULL, [Timestamp] [datetime] NOT NULL, [Value1] [decimal](18, 2) NULL, [Value2] [decimal](18, 2) NULL, [Value3] [decimal](18, 2) NULL, CONSTRAINT [PK_DemoUnitData] PRIMARY KEY CLUSTERED ( [UnitID] ASC, [Timestamp] ASC ) ) GO ALTER …

2
関連しない列は、selectステートメントのクエリ時間に影響しますか?
気になるだけです。 100万レコード/行のテーブルがあるとします。 select order_value from store.orders そのテーブルに実際のクエリ時間で1つのフィールド、2つのフィールド、または100のフィールドがあるかどうかに違いはありますか?「order_value」以外のすべてのフィールドを意味します。 現在、私はデータウェアハウスにデータをプッシュしています。「将来、いつか使用される可能性がある」フィールドをテーブルにダンプすることがありますが、現時点では、何も照会されていません。これらの「無関係な」フィールドは、それらを含まないselectステートメントに直接または間接的に影響しますか(いいえ*意味します)?

1
READPASTヒントにより、インデックス付きビューが無視されるのはなぜですか?
このREADPASTヒントを使用して、アプリケーションの金融サブシステムのリソースロックを削減することを調査しています。 金融取引記録は追加されるだけで、更新または削除されることはないため、良い方法のように思えました。スキップされる行は、トランザクション内に挿入された新しい行のみです。トランザクションがコミットされるまで、それらは事実上外界には存在しません。 ただし、READPASTヒントを付けたインデックス付きビューを使用するクエリのパフォーマンスが低下していることに気付きました。クエリプランを比較すると、ヒントのように見えます。クエリオプティマイザーは、インデックス付きビューを使用しないことを選択し、代わりに通常のビューのように扱います。 それがなぜかはわかりません。インデックス付きビューは、操作中にキーをロックでき、追加READPASTも同様に機能するという点で、他のインデックスと同じだと思います。 SELECT TOP 1 isa.InvoiceId FROM Financial_InvoiceSummaryAmounts isa WITH (READPAST) WHERE isa.TotalOwedAmount = 0.0 SELECT TOP 1 isa.InvoiceId FROM Financial_InvoiceSummaryAmounts isa WHERE isa.TotalOwedAmount = 0.0 NOEXPANDヒントの追加も機能するようですREADPASTが、クエリオプティマイザーがそもそもなぜ(完全な回答の一部として)選択したのか、おそらくその理由について詳しく知りたいと思います。

3
フィルタリングされたインデックスは、フィルタリングされたパーツがWHEREではなくJOINにある場合にのみ使用されます
以下のフィルターされたインデックスを作成しましたが、2つのクエリをさらに実行すると、このインデックスは、where句ではなく、JOINにEND_DTTMがある最初の例のシークにのみ使用されます(クエリの唯一の違いです)。 。なぜこれが起こるのか誰かが説明できますか? インデックスの作成 CREATE NONCLUSTERED INDEX [ix_PATIENT_LIST_BESPOKE_LIST_ID_includes] ON [dbo].[PATIENT_LIST_BESPOKE] ( [LIST_ID] ASC, [END_DTTM] ASC ) WHERE ([END_DTTM] IS NULL) クエリ DECLARE @LIST_ID INT = 3655 --This one seeks on the index SELECT PATIENT_LISTS.LIST_ID FROM DBO.PATIENT_LISTS LEFT JOIN DBO.PATIENT_LIST_BESPOKE ON PATIENT_LISTS.LIST_ID = PATIENT_LIST_BESPOKE.LIST_ID AND PATIENT_LIST_BESPOKE.END_DTTM IS NULL WHERE PATIENT_LISTS.LIST_ID = @LIST_ID …

2
SQL Serverフルテキストインデックスを有効にした後、クエリの更新が遅くなる
asp.net Webサイトで、データベースに対して実行される挿入、更新、削除のクエリが多数あります。 数日前に、1つのテーブルの2つの列にフルテキストインデックスを作成します。その後、Webサイトがそのテーブルに対して更新クエリを実行すると、SQL Serverプロセスのメモリとディスクの使用量が急激に増加し、更新が遅くなることがわかりました。クエリは、フルテキストインデックスを作成する前に、パフォーマンスの問題なしに実行されました。 以前は非常に単純だった更新クエリが複雑になっていることにも気づきました。これは、実行プランに全文インデックスの更新などがあるためです。これは、フルテキストを有効にした後に複雑になった新しい実行プランの一部です。 サイトのコンテンツを更新する数時間で、5000の更新クエリを実行しました。フルテキストインデックス処理は、各行で毎回行われると思います。 行の更新の開始時に全文スキャンを無効にしてから、再度有効にする必要がありますか(この関連質問のように)? SQL Serverにフルテキストインデックス作成を5分間停止してから、新しいデータのインデックス作成を開始するように指示できますか? より良い代替手段はありますか?SQL Server 2012を使用しています。

1
このクエリで主(クラスター)キーが使用されないのはなぜですか?
スキーマ構造が次のようなSQL Server 2008 R2テーブルがあります。 CREATE TABLE [dbo].[CDSIM_BE] ( [ID] [bigint] NOT NULL, [EquipmentID] [varchar](50) NOT NULL, [SerialNumber] [varchar](50) NULL, [PyrID] [varchar](50) NULL, [MeasMode] [varchar](50) NULL, [ReadTime] [datetime] NOT NULL, [SubID] [varchar](15) NULL, [ProbePosition] [float] NULL, [DataPoint] [int] NULL, CONSTRAINT [PK_CDSIM_BE] PRIMARY KEY CLUSTERED ([ID] ASC, [EquipmentID] ASC, [ReadTime] ASC) WITH …

2
行の見積もりが大幅に不正確であるため、フルテキスト検索が遅い
このデータベースに対するフルテキストクエリ(RT(リクエストトラッカー)チケットを格納する)は、実行に非常に長い時間がかかるようです。添付ファイルテーブル(フルテキストデータを含む)は約15GBです。 データベーススキーマは次のとおりで、約200万行です。 rt4 =#\ d +添付ファイル テーブル "public.attachments" コラム| タイプ| 修飾子| ストレージ| 説明文 ----------------- + ----------------------------- +- -------------------------------------------------- ------ + ---------- + ------------- id | 整数| nullではないデフォルトのnextval( 'attachments_id_seq' :: regclass)| プレーン| transactionid | 整数| nullではない| プレーン| 親| 整数| nullではないデフォルト0 | プレーン| メッセージID | キャラクター変化(160)| | 拡張| 件名| 文字の変化(255)| | 拡張| …

2
MySQL:左外部結合と内部結合のどちらが良い結合か
それらすべてが同じ結果を提供する場合、どの結合がより良いパフォーマンスを発揮しますか?たとえば、2つのテーブルemployees(emp_id,name, address, designation, age, sex)とがありwork_log(emp_id,date,hours_wored)ます。いくつかの具体的な結果を得るために、両方のinner joinとleft join同じ結果になります。しかし、私はまだこの疑問だけに限定されない疑問をいくつか抱えています。 同じ結合の場合、同じ結果値の場合にどちらが優先されるのでしょうか。 結合を適用するときに考慮しなければならない他の要素は何ですか? 内部結合とクロス結合の間に関係はありますか?


4
ギャップとアイランド:クライアントソリューションとT-SQLクエリ
ギャップとアイランドのT-SQLソリューションは、クライアントで実行されているC#ソリューションよりも速く実行できますか? 具体的には、いくつかのテストデータを提供します。 CREATE TABLE dbo.Numbers ( n INT NOT NULL PRIMARY KEY ) ; GO INSERT INTO dbo.Numbers ( n ) VALUES ( 1 ) ; GO DECLARE @i INT ; SET @i = 0 ; WHILE @i < 21 BEGIN INSERT INTO dbo.Numbers ( n ) SELECT n + …

1
クエリの最適化:時間間隔
主に、2種類の時間間隔があります。 presence time そして absence time absence time さまざまなタイプ(休憩、欠席、特別な日など)にすることができ、時間間隔が重複したり交差したりする場合があります。 生データに存在する区間のもっともらしい組み合わせだけが存在するかどうかは確かではありません。存在間隔の重複は意味がありませんが、存在する場合があります。結果として得られるプレゼンスタイムインターバルをさまざまな方法で特定しようとしましたが、私にとって、最も快適なのは次のインターバルのようです。 ;with "timestamps" as ( select "id" = row_number() over ( order by "empId", "timestamp", "opening", "type" ) , "empId" , "timestamp" , "type" , "opening" from ( select "empId", "timestamp", "type", case when "types" = 'starttime' then 1 else -1 …

3
これら2つのクエリは論理的に同等ですか?
これら2つのクエリは論理的に同等ですか? DECLARE @DateTime DATETIME = GETDATE() クエリ1 SELECT * FROM MyTable WHERE Datediff(DAY, LogInsertTime, @DateTime) > 7 クエリ2 SELECT * FROM MyTable WHERE LogInsertTime < @DateTime - 7 それらが論理的に同等でない場合、WHERE句がインデックスを効果的に使用できるように(つまり、関数のラッピングを排除する)ために、最初のクエリと論理的に同等のものを提供できますか?

3
TSQLのパフォーマンス-値の最小値と最大値の間のJOIN
私が保存している2つのテーブルがあります。 IP範囲-国ルックアップテーブル 異なるIPからのリクエストのリスト IPはbigints として保存され、ルックアップのパフォーマンスが向上しました。 これはテーブル構造です: create table [dbo].[ip2country]( [begin_ip] [varchar](15) NOT NULL, [end_ip] [varchar](15) NOT NULL, [begin_num] [bigint] NOT NULL, [end_num] [bigint] NOT NULL, [IDCountry] [int] NULL, constraint [PK_ip2country] PRIMARY KEY CLUSTERED ( [begin_num] ASC, [end_num] ASC ) ) create table Request( Id int identity primary key, [Date] datetime, …

3
並列実行のためにスカラー関数をTVF関数に変換-引き続きシリアルモードで実行
の私のクエリの1つは、リリース後にシリアル実行モードで実行されていましたが、アプリケーションから生成されたLINQ to SQLクエリで参照されるビューで2つの新しい関数が使用されていることに気付きました。そのため、これらのSCALAR関数をTVF関数に変換しましたが、クエリはシリアルモードで実行されています。 以前、他のいくつかのクエリでスカラーからTVFへの変換を実行し、強制的なシリアル実行の問題を解決しました。 これがスカラー関数です: CREATE FUNCTION [dbo].[FindEventReviewDueDate] ( @EventNumber VARCHAR(20), @EventID VARCHAR(25), @EventIDDate BIT ) RETURNS DateTime AS BEGIN DECLARE @CurrentEventStatus VARCHAR(20) DECLARE @EventDateTime DateTime DECLARE @ReviewDueDate DateTime SELECT @CurrentEventStatus = (SELECT cis.EventStatus FROM CurrentEventStatus cis INNER JOIN Event1 r WITH (NOLOCK) ON (cis.Event1Id = r.Id) WHERE (r.EventNumber = …

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