タグ付けされた質問 「index-tuning」

有用なインデックスと有用でないインデックスを決定するプロセス。

3
複合インデックスは、最初のフィールドのクエリにも適していますか？
フィールドAとを持つテーブルがあるとしましょうB。A+ Bで定期的にクエリを作成するため、で複合インデックスを作成しました(A,B)。クエリAも複合インデックスによって完全に最適化されますか？ さらに、にインデックスを作成しましたAが、Postgresはでのみクエリに複合インデックスを使用していAます。前の答えが正の場合、それは実際には重要ではないと思いますが、単一のAインデックスが利用可能な場合、デフォルトで複合インデックスを選択するのはなぜですか？
1
特定の複数列インデックスの代わりに、多くの単一フィールドインデックスを使用する必要がありますか？
この質問は、SQL Serverのインデックス作成手法の有効性に関するものです。「インデックスの交差点」として知られていると思います。 多数のパフォーマンスと安定性の問題がある既存のSQL Server（2008）アプリケーションを使用しています。開発者は、インデックス作成に関して奇妙なことをしました。私はこれらの問題に関する決定的なベンチマークを得ることができませんでしたし、インターネット上で本当に良いドキュメントを見つけることもできませんでした。 テーブルには多くの検索可能な列があります。開発者は、検索可能な各列に単一の列インデックスを作成しました。理論は、SQL Serverはこれらの各インデックスを結合（交差）して、ほとんどの状況でテーブルに効率的にアクセスできるというものでした。簡単な例を次に示します（実際のテーブルにはさらにフィールドがあります）。 CREATE TABLE [dbo].[FatTable]( [id] [bigint] IDENTITY(1,1) NOT NULL, [col1] [nchar](12) NOT NULL, [col2] [int] NOT NULL, [col3] [varchar](2000) NOT NULL, ... CREATE NONCLUSTERED INDEX [IndexCol1] ON [dbo].[FatTable] ( [col1] ASC ) CREATE NONCLUSTERED INDEX [IndexCol2] ON [dbo].[FatTable] ( [col2] ASC ) select * from …
2
複数列のインデックスとパフォーマンス
複数列のインデックスを持つテーブルがあり、クエリのパフォーマンスを最大にするためのインデックスの適切な並べ替えについて疑問があります。 シナリオ： PostgreSQL 8.4、約100万行のテーブル 列c1の値には、約100の異なる値を指定できます。値は均等に分布していると想定できるため、可能な値ごとに約10000行あります。 列c2には1000個の異なる値を指定できます。可能な値ごとに1000行あります。 データを検索するとき、条件には常にこれら2つの列の値が含まれるため、テーブルにはc1とc2を組み合わせた複数列のインデックスがあります。フィルタリングに1列のみを使用するクエリがある場合、複数列インデックスの列を適切に順序付けることの重要性について読みました。これは、このシナリオには当てはまりません。 私の質問はこれです： フィルターの1つが非常に小さなデータセットを選択するという事実を考えると、最初のインデックスが最も選択的なインデックス（より小さなセットを許可するインデックス）である場合、パフォーマンスを改善できますか？参照記事のグラフィックを見るまで、この質問を考えたことはありませんでした。 複数列インデックスについての参照記事から抜粋した画像。 クエリは、フィルタリングに2つの列の値を使用します。フィルタリングに1列のみを使用するクエリはありません。それらはすべて次のとおりWHERE c1=@ParameterA AND c2=@ParameterBです。次のような条件もあります。WHERE c1 = "abc" AND c2 LIKE "ab%"
2
インデックスの数が多すぎる/いついるかを知る方法は？
Microsoft SQL Server Profilerを時々実行すると、作成する新しいインデックスと統計情報がたくさんあります（「... 97％の改善が見込まれる...」）。 私の理解から、追加されたすべてのインデックスは、SQL SELECTクエリを高速化できますが、インデックスを調整する必要があるため、クエリも低速化UPDATEできINSERTます。 私が疑問に思うのは、いつ「多すぎる」インデックス/統計がありますか？ たぶんこれに関する明確な答えはありませんが、いくつかの経験則があります。
1
インデックス：ノードの数が同じ場合の整数と文字列のパフォーマンス
PostgreSQL（9.4）データベースを使用してRuby on Railsでアプリケーションを開発しています。私のユースケースでは、アプリケーションの全体のポイントはモデル上の非常に特定の属性を検索するため、テーブルの列は非常に頻繁に検索されます。 私は現在、使用するかどうかを決定していますintegerタイプを、または単に（例えば、一般的な文字列型を使用character varying(255)、Railsのではデフォルトである私は、性能差がインデックスにどうなるかわからないよう、列に対して）。 これらの列は列挙型です。可能な値の量に対して固定サイズがあります。ほとんどの列挙の長さは5を超えません。これは、アプリケーションの存続期間中、インデックスが多少固定されることを意味します。したがって、整数と文字列のインデックスはノードの数が同じになります。 ただし、インデックス付けされる文字列の長さは約20文字で、メモリ内では整数の約5倍になります（整数が4バイトで、文字列が1文字あたり1バイトの純粋なASCIIの場合、これは成り立ちます）。私は、データベースエンジンがインデックスのルックアップを行う方法を知りませんが、それが一致するまで、それは「スキャン」の文字列に必要がある場合は、正確にそして本質的には、手段は、文字列検索が遅くなる整数のルックアップよりも5倍になるということ。整数ルックアップに一致するまでの「スキャン」は20ではなく4バイトになります。これが私が想像していることです。 ルックアップ値は（整数）4です。 スキャン.................. FOUND | レコードを取得しています... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | BYTE_8 | ... | ルックアップ値は（string） "some_val"（8バイト）です。 走査................................................. ....................................見つかった| レコードを取得しています... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 …
4
データベースに挿入が1つしかない場合、可能なすべての列の組み合わせにインデックスを付けるのは悪いことですか？
私は、大規模な選択クエリを必要とするレポートシステムに取り組んでいますが、データベースは一度しか入力されていません。データベース管理システムはMicrosoft SQL Server 2017です。このようなシステムを設計するより良い方法はおそらくありますが、理論的にこれにアプローチしましょう。 理論的に言えば： 非常に大きなデータベース（複数のテーブルに1億5000万行以上）がある場合 また、データベースには一度しかデータが入力されないと想定できます。 可能なすべての列の組み合わせにインデックスを付けると、選択クエリのパフォーマンスに悪影響が出る可能性がありますか？
4
ID列のインデックスは非クラスター化する必要がありますか？
ID列を持つテーブルの場合、ID列に対してクラスター化または非クラスター化PK /一意のインデックスを作成する必要がありますか？ その理由は、クエリ用に他のインデックスが作成されるためです。非クラスター化インデックス（ヒープ上）を使用し、インデックスでカバーされない列を返すクエリは、余分なクラスター化インデックスBツリーシークステップがないため、使用する論理I / O（LIO）が少なくなりますか？ create table T ( Id int identity(1,1) primary key, -- clustered or non-clustered? (surrogate key, may be used to join another table) A .... -- A, B, C have mixed data type of int, date, varchar, float, money, .... B .... C .... ....) create …
1
選択されているインデックス付きビューのクラスター化インデックスに含まれる要因は何ですか？
簡単に言えば、 オプティマイザによるインデックス付きビューのインデックスの選択をクエリする要因は何ですか？ 私にとって、インデックス付きビューは、オプティマイザーがインデックスを選択する方法について理解していることに反しているようです。私が見てきた、これは前に尋ねたが、OPはあまり好評ではなかったです。 私は本当に道しるべを探していますが、擬似的な例を作成してから、多くのDDL、出力、例を含む実際の例を投稿します。 私はEnterprise 2008+を使用していると仮定し、理解します with(noexpand) 疑似の例 この擬似的な例を見てみましょう。22個の結合、17個のフィルター、1000万行のテーブルを横断するサーカスポニーを含むビューを作成します。このビューは、実現するのに高価です（ええ、大文字のE）。SCHEMABINDとビューのインデックスを作成します。それから SELECT a,b FROM AnIndexedView WHERE theClusterKeyField < 84。私を回避するオプティマイザーロジックでは、基になる結合が実行されます。 結果： ヒントなし：720行で4825の読み取り、76ミリ秒で47 CPU、0.30523の推定サブツリーコスト。 ヒントあり：17読み取り、720行、4ミリ秒で15 CPU、0.007253の推定サブツリーコスト ここで何が起こっているのでしょうか？Enterprise 2008、2008 -R2、および2012で試してみました。ビューのインデックスを使用すると考えられるすべてのメトリックで、はるかに効率的です。これはアドホックであるため、パラメータスニッフィングの問題やデータの偏りはありません。 実際の（長い）例 あなたが自虐的なタッチでない限り、おそらくこの部分を読む必要はないでしょう。 バージョン うん、企業。 Microsoft SQL Server 2012-11.0.2100.60（X64）2012年2月10日19:39:15 Copyright（c）Microsoft Corporation Enterprise Edition（64-bit）on Windows NT 6.2（Build 9200：）（ハイパーバイザー） 景色 CREATE VIEW dbo.TimelineMaterialized WITH SCHEMABINDING AS SELECT TM.TimelineID, …
2
IS NULL値のフィルター選択されたインデックスが使用されないのはなぜですか？
次のようなテーブル定義があると仮定します。 CREATE TABLE MyTab ( ID INT IDENTITY(1,1) CONSTRAINT PK_MyTab_ID PRIMARY KEY ,GroupByColumn NVARCHAR(10) NOT NULL ,WhereColumn DATETIME NULL ) そして、次のようなフィルター処理された非クラスター化インデックス： CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn ON MyTab (GroupByColumn) WHERE (WhereColumn IS NULL) このインデックスがこのクエリで「カバー」されていない理由： SELECT GroupByColumn ,COUNT(*) FROM MyTab WHERE WhereColumn IS NULL GROUP BY GroupByColumn 私はこの実行計画を取得しています： KeyLookupは、WhereColumn IS NULL述語用です。 計画は次のとおりです。https：//www.brentozar.com/pastetheplan/？id …
2
3500万行以上のテーブルに対応する効果的なmysqlテーブル/インデックスデザイン、200以上の対応する列（ダブル）、任意の組み合わせをクエリ可能
次の状況でのテーブル/インデックスの設計に関するアドバイスを探しています。 複合主キー（assetid（int）、date（date））を含む大きなテーブル（株価履歴データ、InnoDB、3500万行および成長）があります。価格情報に加えて、各レコードに対応する必要がある200のdouble値があります。 CREATE TABLE `mytable` ( `assetid` int(11) NOT NULL, `date` date NOT NULL, `close` double NOT NULL, `f1` double DEFAULT NULL, `f2` double DEFAULT NULL, `f3` double DEFAULT NULL, `f4` double DEFAULT NULL, ... skip a few … `f200` double DEFAULT NULL, PRIMARY KEY (`assetid`, `date`)) ENGINE=`InnoDB` DEFAULT CHARACTER …
3
SQL Serverがインデックスを無視するのはなぜですか？
CustPassMaster16列のテーブルがありCustNum varchar(8)、その1つがであり、indexを作成しましたIX_dbo_CustPassMaster_CustNum。SELECTステートメントを実行すると： SELECT * FROM dbo.CustPassMaster WHERE CustNum = '12345678' インデックスを完全に無視します。これは、CustDataMasterもう少し多くの列（55）を持つテーブルがあり、そのうちの1つが混乱しているためですCustNum varchar(8)。IX_dbo_CustDataMaster_CustNumこのテーブルのこの列（）にインデックスを作成し、実質的に同じクエリを使用します。 SELECT * FROM dbo.CustDataMaster WHERE CustNum = '12345678' そして、作成したインデックスを使用します。 この背後に特定の理由はありますか？なぜインデックスを使用しますが、インデックスを使用しCustDataMasterませんCustPassMasterか？列数が少ないためですか？ 最初のクエリは66行を返します。2番目の場合、1行が返されます。 また、追加のメモ：CustPassMaster4991レコードがあり、CustDataMaster5376レコードがあります。これがインデックスを無視する理由になりますか？CustPassMasterまた、同じCustNum値を持つ重複レコードもあります。これは別の要因ですか？ この主張は、両方のクエリの実際の実行計画の結果に基づいています。 CustPassMaster（未使用のインデックスを持つもの）のDDLは次のとおりです。 CREATE TABLE dbo.CustPassMaster( [CustNum] [varchar](8) NOT NULL, [Username] [char](15) NOT NULL, [Password] [char](15) NOT NULL, /* more columns here */ [VBTerminator] [varchar](1) NOT NULL …
2
PostgreSQLインデックスキャッシング
PostgreSQLでのインデックスのキャッシュ方法に関する「わかりやすい」説明を見つけるのが難しいので、これらの仮定のいずれかまたはすべてを現実的にチェックしたいと思います。 行のようなPostgreSQLインデックスはディスク上に存在しますが、キャッシュされる場合があります。 インデックスは完全にキャッシュ内にある場合とまったくない場合があります。 キャッシュされるかどうかは、それが使用される頻度に依存します（クエリプランナーが定義）。 このため、ほとんどの「賢明な」インデックスは常にキャッシュに置かれます。 インデックスbuffer cacheは行と同じキャッシュ（？）に存在するため、インデックスで使用されるキャッシュスペースは行で使用できません。 これを理解する動機は、データの大部分が決してアクセスされないテーブルで部分インデックスを使用できると示唆された別の質問に続いています。 これを実行する前に、部分インデックスを使用すると2つの利点が得られることを明確にしたいと思います。 キャッシュ内のインデックスのサイズを小さくし、キャッシュ内の行自体により多くのスペースを解放します。 Bツリーのサイズを小さくして、クエリの応答を高速化します。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.