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

メンテナンスジョブ中に、断片化されたインデックスのリストを取得しようとしています。しかし、クエリは非常に遅く、実行に30分以上かかります。これはsys.dm_db_index_physical_statsのリモートスキャンによるものだと思います。 次のクエリを高速化する方法はありますか？ SELECT OBJECT_NAME(i.OBJECT_ID) AS TableName, i.name AS TableIndexName FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat INNER JOIN sys.indexes i ON i.OBJECT_ID = phystat.OBJECT_ID AND i.index_id = phystat.index_id WHERE phystat.avg_fragmentation_in_percent > 20 AND OBJECT_NAME(i.OBJECT_ID) IS NOT NULL ORDER BY phystat.avg_fragmentation_in_percent DESC 私はDBAではないので、上記のクエリで明らかな間違いを犯している可能性があります。または、役立つインデックスまたは統計があるかもしれません。たぶん、それはデータベースのサイズだけです（約140のテーブルで約20Gb）。 私が尋ねる理由は、夜中にメンテナンスのための非常に小さなウィンドウしかなく、これがほとんどの時間を占めているからです。

14 sql-server  index  query-performance  maintenance  dmv 

クエリウィンドウで2秒で実行される複雑なクエリがありますが、ストアドプロシージャとしては約5分です。なぜストアドプロシージャとして実行するのにこれほど時間がかかるのですか？ クエリは次のようになります。 それは（によって識別されたレコードの特定のセット取り@idと@createdDate）、および特定の時間枠（から始まる1年間@startDateそれらの手紙の結果として受け取った手紙の要約リストが送られた）とリターンと推定支払いを。 CREATE PROCEDURE MyStoredProcedure @id int, @createdDate varchar(20), @startDate varchar(20) AS SET NOCOUNT ON -- Get the number of records * .7 -- Only want to return records containing letters that were sent on 70% or more of the records DECLARE @limit int SET @limit = IsNull((SELECT Count(*) …

14 sql-server-2005  stored-procedures  query-performance 

いくつかの仮定をしてみましょう。 次のような表があります。 a | b ---+--- a | -1 a | 17 ... a | 21 c | 17 c | -3 ... c | 22 私のセットに関する事実： テーブル全体のサイズは〜10 10行です。 私は値で〜100kの行を持ってa列内のa他の値（例えばについても同様、c）。 これは、列 'a'に〜100k個の異なる値があることを意味します。 私のクエリのほとんどは、aの特定の値のすべてまたはほとんどの値を読み取りますselect sum(b) from t where a = 'c'。 テーブルは、連続した値が物理的に近くなるように記述されます（順番に記述されているかCLUSTER、そのテーブルと列で使用されていると仮定しますa）。 テーブルが更新されることはめったにありません。読み取り速度のみが重要です。 テーブルは比較的狭い（タプルごとに〜25バイト、+ 23バイトのオーバーヘッドなど）。 問題は、どのようなインデックスを使用する必要があるかということです。私の理解は： BTreeここでの私の問題は、BTreeインデックスが重複する値を格納することを知っている限り、巨大になることです（テーブルが物理的にソートされていると想定できないため、必要です）。BTreeが巨大な場合、インデックスとインデックスが指すテーブルの部分の両方を読み取る必要があります。（fillfactor = 100インデックスのサイズを少し小さくするために使用できます。） BRIN私の理解では、役に立たないページを読むことを犠牲にして、ここに小さなインデックスを作成できるということです。小さな値を使用pages_per_rangeすると、インデックスが大きくなり（インデックス全体を読み取る必要があるためBRINで問題になります）、大きな値を使用pages_per_rangeすると、多くの無駄なページを読み取ることになります。pages_per_rangeそれらのトレードオフを考慮に入れた優れた価値を見つけるための魔法の公式はありますか？ GIN …

14 postgresql  index  query-performance  clustered-index  postgresql-9.6 

SQL Server 2012の2つのクエリを比較しています。目標は、最適なクエリを選択するときに、クエリオプティマイザーから利用可能な関連情報をすべて使用することです。両方のクエリは同じ結果を生成します。すべての顧客の最大注文ID。 FREEPROCCACHEおよびDROPCLEANBUFFERSを使用して各クエリを実行する前に、バッファプールをクリアしました 以下の情報を使用して、どのクエリがより良い選択ですか？ -- Query 1 - return the maximum order id for a customer SELECT orderid, custid FROM Sales.Orders AS O1 WHERE orderid = (SELECT MAX(O2.orderid) FROM Sales.Orders AS O2 WHERE O2.custid = O1.custid); -- Query 2 - return the maximum order id for a customer SELECT …

14 sql-server-2012  query-performance 

私は何時間もグーグルで独学で解決策を探していましたが、運がありませんでした。ここではいくつかの同様の質問を見つけましたが、この場合は見つかりませんでした。 私のテーブル： 人（〜1000万行） 属性（場所、年齢、...） 人と属性の間のリンク（M：M）（〜40M行） フルダンプ〜280MB 状況：person_idいくつかの場所（location.attribute_value BETWEEN 3000 AND 7000）、性別（gender.attribute_value = 1）、生まれた年（bornyear.attribute_value BETWEEN 1980 AND 2000）、目の色（eyecolor.attribute_value IN (2,3)）から すべての個人ID（）を選択しようとしています。 これは私の魔女が3〜4 分かかったクエリです。最適化したい： SELECT person_id FROM person LEFT JOIN attribute location ON location.attribute_type_id = 1 AND location.person_id = person.person_id LEFT JOIN attribute gender ON gender.attribute_type_id = 2 AND gender.person_id = person.person_id …

14 mysql  performance  query-performance  optimization  eav 

を使用するselect *と、読み取りがはるかに少ないだけでなく、使用するよりも大幅に少ないCPU時間を使用するクエリがありますselect c.Foo。 これはクエリです： select top 1000 c.ID from ATable a join BTable b on b.OrderKey = a.OrderKey and b.ClientId = a.ClientId join CTable c on c.OrderId = b.OrderId and c.ShipKey = a.ShipKey where (a.NextAnalysisDate is null or a.NextAnalysisDate < @dateCutOff) and b.IsVoided = 0 and c.ComplianceStatus in (3, 5) …

13 sql-server  sql-server-2014  query-performance  execution-plan 

行の推定が非常に間違っている理由を理解するのに苦労しています、ここに私の場合があります： 単純な結合-SQL Server 2016 sp2を使用（sp1と同じ問題）、dbcompatiblity = 130。 select Amount_TransactionCurrency_id, CurrencyShareds.id from CurrencyShareds INNER JOIN annexes ON Amount_TransactionCurrency_id = CurrencyShareds.Id option (QUERYTRACEON 3604, QUERYTRACEON 2363); SQLは1行を推定しますが、107131であり、ネストされたループを実行することを選択します（planへのリンク）。CurrencySharedsの統計が更新された後、見積もりは問題なく、マージ結合が選択されます（新しいプランへのリンク）。CurrencySharedsに1つのレコードが追加されるとすぐに、統計が「古く」なり、sqlが誤った推定に戻ります。 この単純なクエリについてはあまり心配しませんが、これは大きなクエリの一部に過ぎず、これはドミノの始まりです... 1つの行を100レコードテーブルに追加すると、このような損傷が発生するのはなぜですか？カーディナリティ推定トレースの出力を調べると、この警告***WARNING: badly-formed histogram ***が表示されますが、このトピックに関する詳細は見つかりませんでした。 ここに、カーディナリティ推定からの完全な出力が出力されます： Begin selectivity computation Input tree: LogOp_Join CStCollBaseTable(ID=1, CARD=107131 TBL: annexes) CStCollBaseTable(ID=2, CARD=100 TBL: CurrencyShareds) ScaOp_Comp x_cmpEq ScaOp_Identifier QCOL: [test.MasterData].[dbo].[CurrencyShareds].Id …

13 sql-server  query-performance  sql-server-2016  cardinality-estimates 

これは、実際の問題から少し逸脱しています。コンテキストの提供が役立つ場合、このデータの生成は、文字列の処理方法のパフォーマンステスト、カーソル内で何らかの操作を適用する必要がある文字列の生成、または機密データの一意の匿名名の置換の生成に役立ちます。SQL Server内でデータを効率的に生成する方法に興味があるだけです。このデータを生成する必要がある理由を尋ねないでください。 ある程度正式な定義から始めようと思います。文字列は、A〜Zの大文字のみで構成される場合、シリーズに含まれます。シリーズの最初の用語は「A」です。シリーズは、最初に長さ、2番目に一般的なアルファベット順でソートされたすべての有効な文字列で構成されます。文字列がという列のテーブルにあるSTRING_COL場合、順序はT-SQLでとして定義できますORDER BY LEN(STRING_COL) ASC, STRING_COL ASC。 あまり正式ではない定義を行うには、Excelのアルファベット順の列ヘッダーを見てください。シリーズは同じパターンです。整数を基数26の数値に変換する方法を検討してください。 1-> A、2-> B、3-> C、...、25-> Y、26-> Z、27-> AA、28-> AB、... 「A」は10を基数とする0とは異なる動作をするため、類推は完全ではありません。以下に、選択した値の表を示します。 ╔════════════╦════════╗ ║ ROW_NUMBER ║ STRING ║ ╠════════════╬════════╣ ║ 1 ║ A ║ ║ 2 ║ B ║ ║ 25 ║ Y ║ ║ 26 ║ Z ║ ║ 27 ║ AA ║ …

13 sql-server  query-performance 

運用アプリケーション（SQL Server 2014 Standardと通信するC＃）には、以下のようなクエリがあります。ほとんどの場合、ミリ秒単位で実行されます。ただし、（特定の値の場合@Id）場合によっては非常に時間がかかり、1分ほどかかります。これはアプリのタイムアウトよりも長いため、ユーザーにとってアプリは失敗します。 "goes nuts"の場合、返される結果セットは他のすべてではないが多くの場合にそうであるように、正しく空です。 幸いなことに、これは実稼働環境と開発環境の両方で再現可能です。 開発者は、クエリから「TOP 1」を削除し、アプリが結果セットの余分な行を消費することを確認して、パフォーマンスの問題を解決すると言います。 クエリプランナーは、インデックスTOP 1が存在する場合はインデックスを提案しません。（開発中）。 クエリの変更とアプリの修正が進行中です。ロールアウトには時間がかかります。 私の質問：アプリが新しいクエリで変更される前に、この問題を克服するために、運用SQL Serverインスタンスをチューニングまたは微調整するDBAアクセス可能な方法はありますか？ SELECT TOP 1 subscription_id FROM subscription AS sub JOIN billing_info AS bi ON bi.billing_info_id = sub.billing_info_id JOIN person_group AS apg ON apg.person_id = bi.person_id JOIN pplan ON pplan.plan_id = sub.plan_id JOIN product ON product.product_id = [plan].product_id …

13 sql-server  query-performance  database-tuning 

私はPostgres 9.3.5を使用しており、データベースに大きなテーブルがあります。現在は2500万行以上あり、急速に大きくなる傾向があります。次のような簡単なクエリを使用して、特定の行（すべてunit_idのsに最新のもののみを含む）を選択しようとしていますunit_timestamp。 SELECT unit_id, max(unit_timestamp) AS latest_timestamp FROM all_units GROUP BY unit_id; インデックスがない場合、このクエリの実行には約35秒かかります。定義されたインデックス（CREATE INDEX partial_idx ON all_units (unit_id, unit_timestamp DESC);）を使用すると、クエリ時間は約（わずか）19秒に短縮されます。 クエリをさらに短い時間（ほんの数秒など）で実行できるようになるのではないかと考えています。その場合、クエリをさらに最適化するにはどのような手順を実行する必要がありますか。 テーブル構造のダンプは次のようになります。 CREATE TABLE "all_units" ( "unit_id" int4 NOT NULL, "unit_timestamp" timestamp(6) NOT NULL, "lon" float4, "lat" float4, "speed" float4, "status" varchar(255) COLLATE "default" ) ALTER TABLE "all_units" ADD PRIMARY …

13 postgresql  performance  index  query-performance 

私が取り組んでいるデータ処理システムのパフォーマンスに問題があります。大量のCXPACKETおよびLATCH_EX待機イベントを示す1時間のperoidから待機統計を収集しました。 システムは3つの処理SQL Serverで構成され、多数の数値計算と計算を実行してから、中央のクラスターサーバーにデータを供給します。処理サーバーでは、一度に最大6つのジョブを実行できます。これらの待機統計は、ボットネックを引き起こしていると思われる中央クラスターに関するものです。中央クラスタサーバーには、16コアと64GB RAMがあります。MAXDOPは0に設定されます。 CXPACKETは実行中の複数の並列クエリからのものであると思いますが、LATCH_EX待機イベントが何を示しているのかわかりません。私が読んだことから、これは非バッファ待機かもしれませんか？ これらの種類の待機統計の原因が何であるか、このパフォーマンス問題の根本原因を調査するために私が取るべき措置は何ですか？ 上位のクエリ結果は合計待機統計であり、下位のクエリ結果は1時間の統計です。

13 sql-server  performance  query-performance  parallelism  wait-types 

Employee100万件のレコードを持つテーブルがあります。Webアプリケーションでデータをページングするための次のSQLがあります。正常に動作しています。しかし、私が問題と思うのは、派生テーブルtblEmployeeがEmployeeテーブル内のすべてのレコードを選択することMyRowNumberです（値を作成するため ）。 これにより、Employeeテーブル内のすべてのレコードが選択されると思います。 それは本当にうまくいくのでしょうか？または、SQL Serverは元のEmployeeテーブルから5つのレコードのみを選択するように最適化されていますか？ DECLARE @Index INT; DECLARE @PageSize INT; SET @Index = 3; SET @PageSize = 5; SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY EmpID asc) as MyRowNumber,* FROM Employee) tblEmployee WHERE MyRowNumber BETWEEN ( ((@Index - 1) * @PageSize )+ 1) AND @Index*@PageSize

13 sql-server  query-performance 

かなり簡単な質問で、おそらくどこかで答えられましたが、Googleの正しい検索質問を作成できないようです... 特定のテーブルの列の数は、そのテーブルのサブセットでクエリを実行するとき、クエリのパフォーマンスに影響しますか？ たとえば、テーブルFooに20個の列があり、クエリでそれらの列のうち5個しか選択されていない場合、20個（たとえば10個）の列があるとクエリのパフォーマンスに影響しますか？簡単にするために、WHERE句のすべてがこれらの5つの列に含まれていると仮定します。 オペレーティングシステムのディスクキャッシュに加えて、Postgresのバッファキャッシュの使用が心配です。Postgresの物理ストレージ設計に対する理解が非常に失われています。テーブルは複数のページに保存されます（デフォルトではページごとに8kのサイズに設定されています）が、そこからタプルがどのように配置されているのかよくわかりません。PGは、これら5つの列を構成するデータのみをディスクからフェッチするのに十分スマートですか？

13 postgresql  performance  query-performance 

SentryOne Plan Explorerは広告どおりに機能しますか？それは合法ですか？気をつけるべきことや心配することはありますか？ SSMSの悪夢のような実行計画の見方と比較して、ホットパスを色で示しているように見えます。 私の懸念は-悪意のあるデータやその他のデータを変更しますか？ 編集：私はそれについて聞いたばかりで、会社について聞いたことがありません。

13 sql-server  query-performance  optimization  execution-plan 

セットアップ： create table dbo.T ( ID int identity primary key, XMLDoc xml not null ); insert into dbo.T(XMLDoc) select ( select N.Number for xml path(''), type ) from ( select top(10000) row_number() over(order by (select null)) as Number from sys.columns as c1, sys.columns as c2 ) as N; 各行のサンプルXML： <Number>314</Number> …

13 sql-server  sql-server-2012  query-performance  execution-plan  xml