タグ付けされた質問 「optimization」

SQL Server 2012データベースがあります。私はReason for early termination of statement optimizationいくつかのクエリの価値に気付き、すべてが与えましたGood Enough Plan Found。私の質問は次のとおりです。 「ステートメント最適化の早期終了の理由」のすべての可能なタイプは何ですか。msdnでこれを検索しましたが、値の完全なリストを取得できませんでした。 Good Enough Plan Found以外の理由で最適化が終了したすべてのクエリをリストするDMVまたは拡張イベントはありますか？可能性の完全なリストを掲載していない次の2つの記事を参照しました。[また、私のデータベースでは異なる結果が得られます]。 検出：クエリコンパイルタイムアウト 十分ではないクエリプランの特定

20 sql-server  optimization  execution-plan 

このようなテーブルがあります： CREATE TABLE Updates ( UpdateId INT NOT NULL IDENTITY(1,1) PRIMARY KEY, ObjectId INT NOT NULL ) 基本的に、IDが増加するオブジェクトの更新を追跡します。 このテーブルのコンシューマーはUpdateId、特定のから順に特定の100個のオブジェクトIDのチャンクを選択しますUpdateId。基本的に、中断した場所を追跡し、更新をクエリします。 私はクエリのみ書き込むことによって最大限に最適なクエリプランを生成することができましたので、これは興味深い最適化問題であることがわかってきましたが起こる私はインデックスのためにやりたいが、ないが保証する私が欲しいもの： SELECT DISTINCT TOP 100 ObjectId FROM Updates WHERE UpdateId > @fromUpdateId @fromUpdateIdストアドプロシージャのパラメーターはどこにありますか。 次の計画： SELECT <- TOP <- Hash match (flow distinct, 100 rows touched) <- Index seek UpdateId使用されているインデックスのシークにより、結果は既に素晴らしく、必要な更新IDの最低から最高まで並べられています。そして、これはフロー別の計画を生成します。それは私が望むものです。しかし、順序は明らかに動作を保証するものではないため、使用したくありません。 このトリックにより、同じクエリプランが得られます（ただし、冗長なTOPがあります）。 WITH …

19 sql-server  sql-server-2014  query-performance  optimization 

これは意見の範疇に入るかもしれませんが、人々がSQL Serverの起動パラメーターとしてトレースフラグ4199を使用している場合、私は興味があります。それを使用した人のために、どのような状況でクエリ回帰が発生しましたか？ 確かに全体的なパフォーマンスの向上の可能性があるように思えます。非実稼働環境でグローバルに有効にし、問題を排除するために数か月間放置することを検討しています。 4199の修正は、2014年（または2016年）にデフォルトでオプティマイザーに反映されますか？予期しない計画変更を導入しない場合は理解できますが、バージョン間でこれらの修正をすべて隠しておくのは奇妙に思えます。 2008、2008R2、主に2012を使用しています。

19 sql-server  optimization  execution-plan 

Seven WeeksのSeven Databasesから3日目の最初の宿題の質問に答えるために、2つの関数を作成しました。 好きな映画のタイトルや俳優の名前を入力できるストアドプロシージャを作成すると、俳優が主演した映画または類似のジャンルの映画に基づいて上位5つの候補が返されます。 私の最初の試みは正しいが、遅い。結果を返すには最大2000msかかります。 CREATE OR REPLACE FUNCTION suggest_movies(IN query text, IN result_limit integer DEFAULT 5) RETURNS TABLE(movie_id integer, title text) AS $BODY$ WITH suggestions AS ( SELECT actors.name AS entity_term, movies.movie_id AS suggestion_id, movies.title AS suggestion_title, 1 AS rank FROM actors INNER JOIN movies_actors ON (actors.actor_id = movies_actors.actor_id) …

19 postgresql  optimization  postgresql-9.3 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 最近、「where 1 = 1 statement」という質問を見ました。（ホスト言語の観点から）よりクリーンなコードを作成するために、動的SQLの作成によく使用するSQL構成体。 一般的に、SQLステートメントへのこの追加は、クエリのパフォーマンスに悪影響を及ぼしますか？特定のデータベースシステムに関する回答を探しているわけではありません（DB2、SQL Server、MS-Access、およびmysqlで使用しているためです）。

19 performance  optimization 

日付範囲ごとに100万行以上のテーブルをパーティション分割したいと思います。これは、多くのダウンタイムを必要とせずに、またはデータを失うリスクを負うことなく、通常どのように行われますか？ここに私が検討している戦略がありますが、提案があります： 既存のテーブルがマスターであり、子はそれを継承します。時間が経つにつれて、マスターから子にデータが移動しますが、データの一部がマスター表にあり、一部が子にある期間があります。 新しいマスターテーブルと子テーブルを作成します。子テーブルの既存のテーブルにデータのコピーを作成します（したがって、データは2つの場所に存在します）。子テーブルが最新のデータを取得したら、今後すべての挿入を変更して新しいマスターテーブルを指し、既存のテーブルを削除します。

19 postgresql  optimization  partitioning 

この質問は、IP範囲検索の最適化に似ていますか？ただし、その1つはSQL Server 2000に制限されています。 次のように構造化され、入力されたテーブルに1,000万個の範囲が暫定的に保存されているとします。 CREATE TABLE MyTable ( Id INT IDENTITY PRIMARY KEY, RangeFrom INT NOT NULL, RangeTo INT NOT NULL, CHECK (RangeTo > RangeFrom), INDEX IX1 (RangeFrom,RangeTo), INDEX IX2 (RangeTo,RangeFrom) ); WITH RandomNumbers AS (SELECT TOP 10000000 ABS(CRYPT_GEN_RANDOM(4)%100000000) AS Num FROM sys.all_objects o1, sys.all_objects o2, sys.all_objects o3, sys.all_objects o4) …

18 sql-server  optimization 

テーブル変数を使用すると、オプティマイザーがインデックスシークを使用してからブックマークルックアップとインデックススキャンを使用できなくなる理由を理解しようとしています。 テーブルにデータを入力する： CREATE TABLE dbo.Test ( RowKey INT NOT NULL PRIMARY KEY, SecondColumn CHAR(1) NOT NULL DEFAULT 'x', ForeignKey INT NOT NULL ) INSERT dbo.Test ( RowKey, ForeignKey ) SELECT TOP 1000000 ROW_NUMBER() OVER (ORDER BY (SELECT 0)), ABS(CHECKSUM(NEWID()) % 10) FROM sys.all_objects s1 CROSS JOIN sys.all_objects s2 CREATE INDEX …

18 sql-server  sql-server-2008-r2  optimization  user-defined-table-type  bookmark-lookup 

PostgreSQL 9.3でPL / pgSQL関数を使用し、いくつかの複雑なクエリを内部で使用しています。 create function f1() returns integer as $$ declare event tablename%ROWTYPE; .... .... begin FOR event IN SELECT * FROM tablename WHERE condition LOOP EXECUTE 'SELECT f2(event.columnname)' INTO dummy_return; END LOOP; ... INSERT INTO ... FROM a LEFT JOIN b ... LEFT JOIN c WHERE ... UPDATE …

18 postgresql  optimization  functions  plpgsql  explain 

SQL Server 2008 R2で毎晩レポートを作成する必要があります。レポートの計算には数時間かかります。時間を短縮するために、テーブルを事前計算します。このテーブルは、12の非常に大きな（数百万行）テーブルを結合して作成されます。 この集計テーブルの計算には、数日前までに約4時間かかりました。DBAは、この大きな結合を3つの小さな結合（それぞれ4つのテーブルに結合）に分割しました。一時的な結果は毎回一時テーブルに保存され、次の結合で使用されます。 DBA拡張の結果、集計テーブルは15分で計算されます。私はそれがどのように可能か疑問に思いました。DBAは、サーバーが処理しなければならないデータの数が少ないためだと言いました。言い換えれば、大きな元の結合では、サーバーは合計された小さな結合よりも多くのデータを処理する必要があります。ただし、元の大きな結合でオプティマイザが効率的に処理し、結合をそれ自体で分割し、次の結合に必要な数の列のみを送信すると仮定します。 彼が行ったもう1つのことは、一時テーブルの1つにインデックスを作成したことです。ただし、オプティマイザーは必要に応じて適切なハッシュテーブルを作成し、計算を全体的に最適化すると思います。 私はこれについてDBAと話しましたが、彼は処理時間の改善がどのように行われたのかについては不確かでした。彼は、そのようなビッグデータを計算するのは圧倒される可能性があり、最適化プログラムが最適な実行計画を予測するのに苦労する可能性があるため、サーバーを非難しないと述べました。これは理解していますが、正確な理由についてより明確な答えが欲しいです。 したがって、質問は次のとおりです。 大きな改善をもたらす可能性があるものは何ですか？ 大きな結合を小さな結合に分割する標準的な手順ですか？ 複数の小さな結合の場合、サーバーが処理する必要があるデータの量は本当に少ないですか？ 元のクエリは次のとおりです。 Insert Into FinalResult_Base SELECT TC.TestCampaignContainerId, TC.CategoryId As TestCampaignCategoryId, TC.Grade, TC.TestCampaignId, T.TestSetId ,TL.TestId ,TSK.CategoryId ,TT.[TestletId] ,TL.SectionNo ,TL.Difficulty ,TestletName = Char(65+TL.SectionNo) + CONVERT(varchar(4),6 - TL.Difficulty) ,TQ.[QuestionId] ,TS.StudentId ,TS.ClassId ,RA.SubjectId ,TQ.[QuestionPoints] ,GoodAnswer = Case When TQ.[QuestionPoints] Is null Then 0 …

18 sql-server  optimization  join 

オプティマイザーは、実行可能なすべての実行計画を調査するために必要な時間をすべてとることができないため（実行時間を最小化する必要があります）、カットされることがあります。 これをオーバーライドして、オプティマイザーに必要に応じて常に（または一定のミリ秒単位で）渡すことができるかどうか疑問に思っていました。 この（atm）の必要はありませんが、複雑なクエリがタイトループで実行され、最適なプランを考え出し、それを事前にキャッシュするシナリオを想像できます。 もちろん、ループがタイトであるため、クエリを書き換えて、それがなくなるようにしてください。 これは、好奇心からの質問であり、短絡最適化と完全最適化の間に時々違いがあるかどうかを確認することでもあります。 トレースフラグ2301を使用すると、オプティマイザーにより多くの時間を与えることができます。これは、私が求めていたものとはまったく異なりますが、近づいています。 これについて私が見つけた最高の情報は、Ian JoseによるSQL Server 2005 SP1のQuery Processor Modeling Extensionsにあります。 このトレースフラグは注意して使用してください！しかし、より良い計画を思いつくときに役立ちます。こちらもご覧ください： Grant Fritchey が「最適化レベル」とタグ付けした記事。 SQL Server 2008にアップグレードする前に… Brent Ozar作。 Microsoftサポートにより、高パフォーマンスのワークロードで実行されている場合のSQL Serverのチューニングオプション。 結合順序のソリューション空間が指数関数的に爆発する、多くの結合を持つクエリについて考えていました。SQL Serverが使用するヒューリスティックは非常に優れていますが、時間があれば（数秒から数分）オプティマイザーが別の順序を提案するのではないかと考えていました。

18 sql-server  optimization 

PostgreSQLのGEQO機能に沿った機能を実装する必要があります。GEQOのアプローチはクエリプランを整数文字列としてエンコードすることであり、GEQOはこれらの可能な結合シーケンスをランダムに生成することを理解しています。ソース：http : //www.postgresql.org/docs/9.3/static/geqo-pg-intro.html 私の質問：正しい結合シーケンスを明確に知っている場合にGEQO関数を変更し、異なる結合シーケンスを検索する必要がないようにする方法。たとえば、4つの関係を結合する最適な方法が4-1-3-2であることがわかっていれば、他の順列をチェックする必要はありません。 GEQOがPostgreSQLにどのように実装されているかについての良い資料はありません。PostgreSQLはGEQO機能の全体像のみを提供しますが、あまり説明しません。 または、GEQOを使用せずにstandard_join_search（）自体でこの機能を実現できますか？

16 postgresql  optimization 

テストデータベースに25万行のテーブルがあります。（本番環境には数億個あります。同じ問題があります。）テーブルには、nvarchar2（50）文字列識別子があり、nullではなく、一意のインデックスが付いています（PKではありません）。 識別子は、テストデータベースに8つの異なる値（および運用中に約1000）を持つ最初の部分、@記号、最後に1〜​​6桁の数字で構成されます。たとえば、「ABCD_BGX1741F_2006_13_20110808.xml @」で始まる5万行があり、その後に5万の異なる数字が続く場合があります。 識別子に基づいて単一の行を照会すると、カーディナリティは1と推定され、コストは非常に低く、正常に機能します。IN式またはOR式で複数の識別子を使用して複数の行を照会すると、インデックスの推定が完全に間違っているため、テーブル全体のスキャンが使用されます。ヒントを使用してインデックスを強制すると、非常に高速になります。実際には、テーブル全体のスキャンが1桁遅く実行されます（運用環境でははるかに遅くなります）。それはオプティマイザーの問題です。 テストとして、まったく同じDDLとまったく同じコンテンツを使用してテーブル（同じスキーマ+テーブルスペース）を複製しました。適切な測定のために最初のテーブルに一意のインデックスを再作成し、クローンテーブルにまったく同じインデックスを作成しました。私はDBMS_STATS.GATHER_SCHEMA_STATS('schemaname',estimate_percent=>100,cascade=>true);。インデックス名が連続していることもわかります。したがって、2つのテーブルの唯一の違いは、最初のテーブルが長期間にわたってランダムな順序でロードされ、ブロックがディスクに（他のいくつかの大きなテーブルと一緒にテーブルスペースで）散らばっていることです。 INSERT-SELECT。それ以外、違いは想像できません。（元のテーブルは最後の大規模な削除以降縮小されており、その後の単一の削除はありません。） 病気のテーブルとクローンテーブルのクエリプランを次に示します（黒いブラシの下の文字列は、画像全体で同じであり、灰色のブラシの下でも同じです） （この例では、黒のブラシをかけられた識別子で始まる1867行があります。2行クエリは1867 * 2のカーディナリティを生成し、3行クエリは1867 * 3のカーディナリティを生成します。偶然ですが、Oracleは識別子の終わりを気にしていないようです） この動作の原因は何ですか？本番環境でテーブルを再作成するのは明らかに高価です。 USER_TABLES：http: //i.stack.imgur.com/nDWze.jpg USER_INDEXES：http : //i.stack.imgur.com/DG9um.jpg スキーマとテーブルスペース名のみを変更しました。テーブルとインデックスの名前は、クエリプランのスクリーンショットと同じであることがわかります。

16 oracle  oracle-11g-r2  optimization 

同じSQL Server 2005インスタンスで2つのほぼ同一のクエリを実行しています。 最初のSELECTクエリは、LINQによって生成された元のクエリです（私は知っています、私は知っています...私はアプリケーション開発者ではなく、DBAです:)。 2番目のものは最初のものとまったく同じOPTION (RECOMPILE)で、最後にaが追加されています。 他に変更はありません。 最初のものは、実行のたびに55秒かかります。 2番目は2秒かかります。 両方の結果セットは同じです。 このヒントがパフォーマンスの劇的な向上をもたらすのはなぜですか？ Books OnlineのエントリにRECOMPILEは、あまり詳細な説明はありません。 クエリの実行後にクエリに対して生成されたプランを破棄するようにSQL Serverデータベースエンジンに指示し、同じクエリが次に実行されるときにクエリオプティマイザにクエリプランを再コンパイルさせます。RECOMPILEを指定しないと、データベースエンジンはクエリプランをキャッシュし、それらを再利用します。クエリプランをコンパイルするとき、RECOMPILEクエリヒントは、クエリ内のローカル変数の現在の値を使用し、クエリがストアドプロシージャ内にある場合、現在の値をパラメータに渡します。 RECOMPILEは、ストアドプロシージャ全体ではなく、ストアドプロシージャ内のクエリのサブセットのみを再コンパイルする必要がある場合に、WITH RECOMPILE句を使用するストアドプロシージャを作成するための便利な代替手段です。詳細については、「ストアドプロシージャの再コンパイル」を参照してください。RECOMPILEは、プランガイドを作成するときにも役立ちます。詳細については、「プランガイドを使用したデプロイ済みアプリケーションでのクエリの最適化」を参照してください。 クエリには多くのローカル変数があるため、OPTION (RECOMPILE)クエリヒントを使用すると、SQL Serverは（真剣に）最適化できると推測されます。 私が見ているところはどこでも、それOPTION (RECOMPILE)は避けるべきだと言っている。この説明は、一般に、このヒントを使用すると、SQL Serverはこの実行計画を再利用できないため、毎回再コンパイルする時間を無駄にする必要があるというものです。（しかし）パフォーマンスが非常に優れていることを考えると、今回はこのクエリヒントを使用するのは良いことだと思います。 使用すべきですか？そうでない場合、このヒントとアプリケーションを変更せずに、SQL Serverにより良い実行計画を使用させることができますか？

16 sql-server  sql-server-2005  query-performance  optimization 

私はいくつかの時系列データで単純な選択を区別しています： 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 私のアプリケーションは、多くの異なる操作を実行する必要があり、このようにカウントします。この種のデータを取得するより速い方法はありますか？

16 postgresql  query-performance  optimization  postgresql-9.3  amazon-rds