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

MS SQLデータベースで自動インデックスツールを実行しました（インデックス統計テーブルを参照するMicrosoftのスクリプトを変更しました- 自動自動インデックス作成）。統計から、作成する必要のあるインデックスの推奨事項のリストができました。 編集： 上記のインデックスは、データベースエンジンがインデックスに使用できるものを示すDMVから情報を取得し、スクリプトはTop xの推奨事項（シーク、ユーザーへの影響など）を取得し、テーブルに入れます。 （スクリプトが何をしているのかを明確にするために、下のラリー・コールマンの回答から部分的に取った上記の編集） 私はデータベース管理者が初めてであり、ネット上で簡単に検索したので、思い切って推奨インデックスを盲目的に追加することに消極的です。ただし、この分野での経験がないため、推奨事項が必要かどうかを判断する方法についてのアドバイスを探しています。 SQLプロファイラを実行する必要がありますか、それともテーブルをクエリするコードを調べる方が良いですか？他にアドバイスはありますか？

110 sql-server  performance  index  optimization 

Ubuntu 12.04でPostgreSQL 9.1を使用しています。 時間範囲内のレコードを選択する必要があります。テーブルにtime_limitsは2つのtimestampフィールドと1つのintegerプロパティがあります。実際のテーブルには、このクエリに関係しない追加の列があります。 create table ( start_date_time timestamp, end_date_time timestamp, id_phi integer, primary key(start_date_time, end_date_time,id_phi); このテーブルには、およそ2Mのレコードが含まれています。 次のようなクエリには膨大な時間がかかりました。 select * from time_limits as t where t.id_phi=0 and t.start_date_time <= timestamp'2010-08-08 00:00:00' and t.end_date_time >= timestamp'2010-08-08 00:05:00'; そこで、別のインデックスを追加してみました-PKの逆です： create index idx_inversed on time_limits(id_phi, start_date_time, end_date_time); パフォーマンスが向上したという印象を受けました。テーブルの中央にあるレコードにアクセスする時間は、より合理的であるようです。40〜90秒の間です。 ただし、時間範囲の中央の値の場合はまだ数十秒です。そして、テーブルの終わりをターゲットにすると（時系列的に）、さらに2倍になります。 私explain analyzeは初めてこのクエリプランを取得しようとしました。 Bitmap Heap …

96 postgresql  index  optimization  postgresql-9.1  explain 

分析で使用するために複数の結合からテーブルを作成する場合、新しいテーブルを作成するよりもビューを使用する方が適切ですか？ ビューを使用したい理由の1つは、データベーススキーマが管理者によってRuby内から開発されており、Rubyに詳しくないことです。テーブルの作成をリクエストできますが、追加の手順が必要であり、新しい結合を開発/テストする際の柔軟性を高めたいです。 SO（Rを使用する場合、SQLを使用する場合）に関連する質問への回答に従ってビューを使用し始めました。トップ投票の答えは、「データが単一のテーブルに収まるまでSQLでデータ操作を行い、残りをRで行う」ことから始まります。 ビューの使用を開始しましたが、ビューに関するいくつかの問題に遭遇しました。 クエリははるかに遅い ビューは、分析に使用する実稼働データベースからバックアップデータベースにダンプされません。 ビューはこの用途に適していますか？もしそうなら、パフォーマンスのペナルティを期待すべきですか？ビューのクエリを高速化する方法はありますか？

54 mysql  optimization  view 

以下は、db設計に関する本からの抜粋です（データベース設計の開始ISBN：0-7645-7490-6）： ビューを使用する場合の危険は、ビューに対してクエリをフィルタリングし、非常に大きなテーブルの非常に小さな部分を読み取ることです。ビュー自体に対するフィルタリングは、ビュー内のクエリの実行が完了した後に適用されるため、ビュー内でフィルタリングを実行する必要があります。ビューは通常、開発プロセスの高速化に役立ちますが、長期的にはデータベースのパフォーマンスを完全に低下させる可能性があります。 以下は、PostgreSQL 9.5ドキュメントからの抜粋です。 ビューを自由に使用することは、優れたSQLデータベース設計の重要な側面です。ビューを使用すると、テーブル構造の詳細をカプセル化できます。これは、一貫したインターフェイスの背後で、アプリケーションの進化とともに変化する可能性があります。 2つのソースは互いに矛盾しているようです（「ビューを使用して設計しない」対「ビューを使用して設計する」）。 ただし、PGでは、ビューはルールシステムを使用して実装されます。そのため、おそらく（これが私の質問です）ビューに対するフィルタリングは、ビュー内のフィルターとして書き直され、その結果、基礎となるテーブルに対して1つのクエリが実行されます。 私の解釈は正しく、PGはビューに出入りするWHERE句を組み合わせますか？それとも、それらを次々に別々に実行しますか？短い自己完結型の正しい（コンパイル可能な）例はありますか？

45 postgresql  optimization  view 

次のようなクエリがあります。 DELETE FROM tblFEStatsBrowsers WHERE BrowserID NOT IN ( SELECT DISTINCT BrowserID FROM tblFEStatsPaperHits WITH (NOLOCK) WHERE BrowserID IS NOT NULL ) tblFEStatsBrowsersには553行あります。 tblFEStatsPaperHitsには47.974.301行があります。 tblFEStatsBrowsers： CREATE TABLE [dbo].[tblFEStatsBrowsers]( [BrowserID] [smallint] IDENTITY(1,1) NOT NULL, [Browser] [varchar](50) NOT NULL, [Name] [varchar](40) NOT NULL, [Version] [varchar](10) NOT NULL, CONSTRAINT [PK_tblFEStatsBrowsers] PRIMARY KEY CLUSTERED …

40 sql-server-2008-r2  query  optimization 

最適化しようとしている中程度に複雑なクエリのTOP n場合、句を削除すると実行プランが変更されることに気付きました。クエリにTOP nデータベースエンジンが含まれている場合、TOP句を無視してクエリを実行し、最後にその結果セットを要求されたn行まで縮小するだけだと思いました。グラフィカルな実行計画は、これが事実であることを示しているようです- TOP「最後の」ステップです。しかし、さらに進んでいるようです。 私の質問は、TOP n句がクエリの実行計画にどのように（そしてなぜ）影響するかです。 これは私の場合に起こっていることの単純化されたバージョンです： クエリは、AとBの2つのテーブルの行を照合しています。 TOP句がない場合、オプティマイザは、テーブルAから19k行、テーブルBから46k行があると推定します。返される実際の行数は、Aで16k、Bで13kです。合計69行（ソートが適用されます）。このクエリは非常に高速に発生します。 TOP 1001オプティマイザーを追加するとき、ハッシュ一致を使用しません。代わりに、最初にテーブルAからの結果をソートし（同じ推定値/実際の19k / 16k）、テーブルBに対してネストされたループを実行します。テーブルBの推定行数は1になり、奇妙なことはTOP n、 Bに対する推定実行数（インデックスシーク）-常に2n + 1、または私の場合は2003であるように見えますTOP n。もちろん、これはネストされた結合であるため、実際の実行回数は16k（テーブルAの行数）であり、これによりクエリの速度が低下します。 実際のシナリオはもう少し複雑ですが、これは基本的なアイデア/動作をキャプチャします。両方のテーブルは、インデックスシークを使用して検索されます。これはSQL Server 2008 R2 Enterpriseエディションです。

35 sql-server  query-performance  execution-plan  optimization 

クエリの節のUSING（ではなくON）コンストラクトが、FROMSELECT一定の場合には、最適化の障壁を導入することがあります。 私はこのキーワードを意味します： 選択* から 参加b 使用した（A_ID） より複雑な場合にのみ。 コンテキスト：このコメントにこの質問。 私はこれをよく使いますが、これまでに気づいたことはありません。効果やリンクを示すテストケースに非常に興味があります詳細情報にます。私の検索努力は空っぽになりました。 完璧な答えは、表示するために、テストケースとなりUSING (a_id)、代替句に参加すると比較して劣った性能をON a.a_id = b.a_id- 場合はそれが実際に起こることができます。

35 postgresql  performance  optimization  join  select 

これらの2つのステートメントを調べてみましょう。 IF (CONDITION 1) OR (CONDITION 2) ... IF (CONDITION 3) AND (CONDITION 4) ... 場合はCONDITION 1、IS TRUE、だろうCONDITION 2チェックしますか？ 場合はCONDITION 3、IS FALSE、だろうCONDITION 4チェックしますか？ 条件についてはどうですかWHERE：SQL ServerエンジンはWHERE句内のすべての条件を最適化しますか？SQL Serverオプティマイザーが条件を正しい方法で解決するために、プログラマは条件を正しい順序で配置する必要がありますか？ 追加： リンクを提供してくれたジャックに感謝します。t-sqlコードからの驚きです。 IF 1/0 = 1 OR 1 = 1 SELECT 'True' AS result ELSE SELECT 'False' AS result IF 1/0 = 1 AND …

33 sql-server  sql-server-2008  t-sql  optimization  condition 

このクエリは、フォローしている人が作成した投稿のリストを取得します。フォローできる人の数に制限はありませんが、ほとんどの人は1000人未満をフォローしています。 このスタイルのクエリでは、明らかな最適化は"Post"ID をキャッシュすることですが、残念ながら今のところその時間はありません。 EXPLAIN ANALYZE SELECT "Post"."id", "Post"."actionId", "Post"."commentCount", ... FROM "Posts" AS "Post" INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id" LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id" LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id" LEFT OUTER JOIN "Workouts" AS "workout" ON …

30 postgresql  index  optimization  postgresql-performance 

以下のクエリでは、両方の実行プランが一意のインデックスで1,000シークを実行すると推定されています。 シークは同じソーステーブルでの順序付けされたスキャンによって実行されるため、一見同じ順序で同じ値をシークする必要があります。 両方のネストされたループには <NestedLoops Optimized="false" WithOrderedPrefetch="true"> このタスクのコストが最初の計画では0.172434で、2番目の計画では3.01702である理由を誰もが知っていますか？ （質問の理由は、明らかにはるかに低い計画コストのために、最初のクエリが最適化として私に提案されたためです。 ） セットアップ CREATE TABLE dbo.Target(KeyCol int PRIMARY KEY, OtherCol char(32) NOT NULL); CREATE TABLE dbo.Staging(KeyCol int PRIMARY KEY, OtherCol char(32) NOT NULL); INSERT INTO dbo.Target SELECT TOP (1000000) ROW_NUMBER() OVER (ORDER BY @@SPID), LEFT(NEWID(),32) FROM master..spt_values v1, master..spt_values v2; INSERT INTO dbo.Staging …

27 sql-server  sql-server-2014  optimization 

SELECT DISTINCT TOP NSQL Serverクエリオプティマイザーによる最適化が不十分と思われるいくつかのクエリに遭遇しました。些細な例を考えてみましょう。2つの交互の値を持つ100万行のテーブルです。私が使用しますGetNumsのデータを生成する機能を： DROP TABLE IF EXISTS X_2_DISTINCT_VALUES; CREATE TABLE X_2_DISTINCT_VALUES (PK INT IDENTITY (1, 1), VAL INT NOT NULL); INSERT INTO X_2_DISTINCT_VALUES WITH (TABLOCK) (VAL) SELECT N % 2 FROM dbo.GetNums(1000000); UPDATE STATISTICS X_2_DISTINCT_VALUES WITH FULLSCAN; 次のクエリの場合： SELECT DISTINCT TOP 2 VAL FROM X_2_DISTINCT_VALUES OPTION (MAXDOP 1); …

27 sql-server  optimization  sql-server-2016 

SQL Serverで興味深い問題が発生しました。次の再現例を検討してください。 CREATE TABLE #test (s_guid uniqueidentifier PRIMARY KEY); INSERT INTO #test (s_guid) VALUES ('7E28EFF8-A80A-45E4-BFE0-C13989D69618'); SELECT s_guid FROM #test WHERE s_guid = '7E28EFF8-A80A-45E4-BFE0-C13989D69618' AND s_guid <> NEWID(); DROP TABLE #test; フィドル s_guid <> NEWID()条件が完全に役に立たないように見えることをしばらく忘れてください-これは単なる最小の再現例です。NEWID()特定の定数値と一致する確率は非常に小さいため、毎回TRUEと評価される必要があります。 しかし、そうではありません。このクエリを実行すると、通常 1行が返されますが、時々（非常に頻繁に、10回のうち1回以上）0行が返されます。私のシステムでSQL Server 2008を使用して複製しました。上記のリンク（SQL Server 2014）を使用してオンラインで複製できます。 実行プランを見ると、クエリアナライザーは明らかに条件をs_guid < NEWID() OR s_guid > NEWID()次のように分割していることがわかります。 ...これが失敗する理由を完全に説明します（最初に生成されたIDが小さく、2番目のIDが指定されたIDよりも大きい場合）。 式の1つが非決定的であっても、SQL ServerはA …

26 sql-server  optimization 

私はLIKE、未知のシナリオのすべての最適化で演算子を使用する場合、レガシーと新しいCEの両方が9％の見積もりを使用するという印象を受けました（関連する統計が利用可能であり、クエリオプティマイザーが選択性の推測に頼る必要がないと仮定）。 クレジットデータベースに対して以下のクエリを実行すると、CEごとに異なる推定値が得られます。新しいCEでは、予想していた900行の見積もりを受け取りますが、レガシーCEでは、241.416の見積もりを受け取りますが、この見積もりがどのように導出されるのかわかりません。誰もが光を当てることができますか？ -- New CE (Estimate = 900) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName; -- Forcing Legacy CE (Estimate = 241.416) DECLARE @LastName VARCHAR(15) = 'BA%' SELECT * FROM [Credit].[dbo].[member] WHERE [lastname] LIKE @LastName OPTION ( QUERYTRACEON 9481, QUERYTRACEON 9292, QUERYTRACEON 9204, QUERYTRACEON …

24 sql-server  sql-server-2014  optimization  statistics  cardinality-estimates 

オプティマイザーの動作をよりよく理解し、インデックススプールの制限を理解するために、この質問をしています。ヒープに1〜10000の整数を入れると仮定します。 CREATE TABLE X_10000 (ID INT NOT NULL); truncate table X_10000; INSERT INTO X_10000 WITH (TABLOCK) SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) FROM master..spt_values t1 CROSS JOIN master..spt_values t2; そして、ネストされたループ結合を強制しますMAXDOP 1： SELECT * FROM X_10000 a INNER JOIN X_10000 b ON a.ID = b.ID OPTION (LOOP JOIN, …

23 sql-server  optimization  sql-server-2016  index-spool 

WITHクエリ（共通テーブル式、またはCTE）への頻繁な参照が最適化フェンスとして機能し、サーバーがフィルターをCTEクエリにプッシュダウンしたり、共通式をCTEから取り出したりすることを許可されていないことがよくあります。 SQL標準で要求される動作であるため。 CTEは間違いなくPostgreSQLの最適化フェンスです...しかし、これは標準で必要なのですか、実際には実装の詳細だけですか？ たとえば、これらのメーリングリストの投稿は、それが標準であると主張または示唆しています。 http://www.digipedia.pl/usenet/thread/11566/101385/ コメントでそれを言及した後、私はそれがどこに指定されているのか尋ねられました-そしてSQL：2008の唯一のドラフトを見た後、私はそれを見つける運があまりありません。 私はまだ標準を徹底的に研究していないので、次のような人からの提案を期待しています。もしそうなら、それはどこに指定されていますか？または、Pgメーリングリストのステートメントにエラーがありますか？ ToDoリストのスレッドCTE最適化フェンスも参照してください。。

23 postgresql  optimization  sql-standard