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

WHERE句で使用されているインデックスの最後の列である列を使用するORDER BY句を含むクエリがあります。 SELECT cols FROM tables WHERE col_1 = x AND col_2 = y AND col_3 = z ORDER BY col_4 インデックスは、列（col_1、col_2、col_3、col_4）にこの順序で作成されます。 クエリのプロファイルを作成すると、99％以上の時間を「結果の並べ替え」状態で費やしています。col_4は、違いがある場合はタイムスタンプ列です。ORDER BYは特定の状況でのみインデックスを使用できることを理解していますが、オプティマイザがいつ使用するかについては、まだ少し不思議です。

10 mysql  index  sorting 

ここ数日、postgresで全文検索を行ったことがありますが、複数の列を検索するときのインデックス付けについて少し混乱しています。 postgresのドキュメントではts_vector、次のように、連結された列にインデックスを作成する方法について説明しています。 CREATE INDEX pgweb_idx ON pgweb USING gin(to_tsvector('english', title || ' ' || body)); 私はそのように検索できます： ... WHERE (to_tsvector('english', title||' '||body) @@ to_tsquery('english', 'foo')) ただし、タイトルだけ、本文だけ、または両方を検索する場合は、3つの個別のインデックスが必要になります。そして、3番目の列に追加すると、6つのインデックスになる可能性があります。 私がドキュメントで見たことのない別の方法は、2つの列に別々にインデックスを付けてから、通常のWHERE...ORクエリを使用することです。 ... WHERE (to_tsvector('english', title) @@ to_tsquery('english','foo')) OR (to_tsvector('english', body) @@ to_tsquery('english','foo')) 100万行までの2つをベンチマークしても、基本的にパフォーマンスに違いはないようです。 だから私の質問は： 列を個別にインデックス付けするだけでなく、このようにインデックスを連結したいのはなぜですか？両方の長所と短所は何ですか？ 私の推測では、事前に両方の列だけを検索したい場合（一度に1つずつではない）は、どちらが少ないメモリを使用するかを連結することで1つのインデックスしか必要としないでしょう。

10 postgresql  index  full-text-search 

数百万行のテーブルがあり、そこからクエリを時々実行する必要があります。通常、最初のクエリは非常に遅くなり（約10秒）、その後のクエリは通常、かなり高速になります（約1秒）。数時間後、遅い/その後速いサイクルが再び始まります。 必要なすべてのインデックスが存在し、適切に使用されていることを実行プランで確認しました。パフォーマンスの違いは、インデックスが後続のクエリのために実際にメモリ内にあるためであると思います（私は正しいですか、それとも他にもあります）考えられる原因？） また、インデックスを使用して他の多くのクエリも実行していますが、これらのクエリは時間がかかりませんし、そのパフォーマンスはそれほど重要ではないため、これらのインデックスが実際に重要なインデックスをメモリキャッシュから押し出しているのではないかと心配しています。 「RAMを追加する」という明らかな修正とは別に、インデックスをメモリに強制的に戻すためにダミークエリを1時間ごとに実行するスクリプトを作成することを考えていました。 これを行うよりエレガントな方法はありますか？SQLServerに、1つの単一のインデックスをキャッシュするだけの十分なメモリがある場合、それをキャッシュする必要があることを示唆する方法と同様に、 私は通常、そのようなことに関してSQLServerを台無しにするのが最善ではないことを知っていますが、私のクエリの異常な性質（非常にまれに実行されますが、タイムクリティカル）は、それが理にかなっていると信じています（可能な場合） 。 また、特定の時点でどのインデックスがメモリにキャッシュされているかを知る方法があるかどうか知りたいです。

10 sql-server-2008  performance  index 

とに複数列のUNIQUEインデックスを持つテーブルが_job_id__あり__keyword_id__ます。 その列__job_id__に対してクエリを頻繁に実行する場合、別のインデックスを追加する必要もありGROUP BYますか？ （1億行になると、しばらく時間がかかることがあります。これが、単に実行する代わりに求めている理由です）

10 mysql  index 

実際の多次元インデックスを使用しているデータベースはどれですか？オラクルはテーブルからデータを取得するためにいくつかのインデックスを使用しますか、それとも常に選択性が最も高いと思われるインデックスを使用しますか？他のdbmsはどうですか？

10 index 

インデックスについてこのウェブサイトからの質疑応答を読んだ後、疑問が浮かびました。 もし、1日がより細かいレベルの時間ディメンションテーブルを使用しているとしたらどうでしょう。インデックスはどこに置くべきですか？ 質問のランディ・メルダー：RDBMSで「インデックス」とはどういう意味ですか？言った： インデックスを「目次」と考えてください...これは、ファイル内の位置へのポインタ、つまりオフセットの順序付きリストです 時間ディメンションの場合、ほとんどのデータ調査は特定の日、特定の週、特定の月、または特定の年のすべての日がタイムテーブルに保存されている場合は特定の四半期に対して行われる可能性があります。 私の質問は、これらすべてのフィールドにインデックスを設定する必要がありますか？ 日は一意であると想定されているため、この日についてはインデックスの使用を完全に理解しています。ただし、週IDには7回、月IDには30/31回、四半期IDには120回程度の発生があります。 それらのフィールドにインデックスを付ける必要がありますか？ それはまだ役に立ちますか？ 同じ質問で、David Spillettが言ったので、私はあなたに尋ねます： インデックスを追加することは、もちろん最適化の悪い結果になる可能性があります。インデックスを格納するために使用される余分なスペース（および、DBが多数の書き込み操作を確認した場合にインデックスを維持するためのIO負荷）は、わずかに最適化されていない読み取りクエリよりも悪い問題である可能性があるためです。 、無理しないでください。 それでは、時間ディメンションの場合の最良の考慮事項は何でしょうか？

10 database-design  index  data-warehouse 

SQL Server 2005で、すべてのデータベースがフルモード（1時間ごとのトランザクションログバックアップを使用）である場合、データベースのすべてのインデックスを再構築してデータベースのログファイルを拡張できるかどうかを判断できますか？そして、それはどれくらい成長することができますか？ 正解がない場合は、どのような指示もいただければ幸いです。 前もって感謝します。

10 sql-server-2005  index  maintenance 

Cassandraのドキュメントには、 次の状況ではインデックスを使用しないでください。 カーディナリティの高い列では、大量のレコードに対して少数の結果をクエリするため。以下のカーディナリティの高い列インデックスの使用に関する問題を参照してください。 それは続きます、 カーディナリティの高い列にインデックスを作成すると、個別の値が多くなり、フィールド間のクエリでシークが多くなり、結果が非​​常に少なくなります。10億曲の表では、アーティストではなくライター（通常は各曲に固有の値）で曲を検索するのは、非常に非効率的です。Cassandraビルトインインデックスを使用する代わりに、テーブルをインデックスの形式として手動で維持する方が効率的です。一意のデータを含む列の場合、インデックス付きの列を持つテーブルへのクエリ量が中程度で一定の負荷がかかっていない限り、便宜上インデックスを使用するとパフォーマンスが向上することがあります。 しかし、実際には決して質問に答えることはできません。なぜ非効率なのでしょうか。「手動でテーブルをインデックスの形式として維持する」が何を意味するのか私にはわかりません。ただし、「...クエリの量が中程度である限り、便宜上インデックスを使用するとパフォーマンスが向上する場合があります...」とは多少矛盾します。 これは、PKをいつ、どこで使用できるかを教えようとしているだけですか？非効率とは何ですか？私の理解では、インデックスにヒットするクエリはクラスター内のすべてのノードをクエリする必要があり、各ノードはローカルインデックスでルックアップを実行し、結果が集計されます。ロットの最も遅いノードを待たなければならないため、ネットワークの遅延を支払うことを除いて、これは必ずしも高価ではありません（各インデックスの検索はかなり安価でなければなりません）。ここで何か不足していますか？ しかし、私が膨大な数のアイテムを含むコレクションを持っている場合-まれに-異なるがほとんど一意の属性で検索する必要がある…これは適切な用途ですよね？ veryみんな？IDKは、レプリケーションが3のレプリケーション係数でクラスタの1/3をヒットできるかどうかを意味しますか？

10 index  cassandra 

私はpostgres 9.4を使用しています。 のmessagesスキーマは次のとおりです。メッセージはfeed_idに属し、posted_atを持っています。また、メッセージには親メッセージを含めることができます（返信の場合）。 Table "public.messages" Column | Type | Modifiers ------------------------------+-----------------------------+----------- message_id | character varying(255) | not null feed_id | integer | parent_id | character varying(255) | posted_at | timestamp without time zone | share_count | integer | Indexes: "messages_pkey" PRIMARY KEY, btree (message_id) "index_messages_on_feed_id_posted_at" btree (feed_id, posted_at DESC NULLS …

10 postgresql  index  postgresql-performance  sorting  postgresql-9.4 

（他のテーブルのデータ、計算などに基づいて）新しいデータを挿入する前に、約175万行のテーブルを切り捨てるストアドプロシージャがあります。 基本的なアウトラインは非常に簡単です： テーブルを切り捨て 1回あたり約75,000の「バッチ」に175万行を挿入します。 このプロセスでいつでも明示的にインデックスを再構築する必要があるかどうか疑問に思っていますか？例えば テーブルを切り捨て ALTER INDEX ALL ON xxx REBUILD WITH (FILLFACTOR=90) [または類似の何か] 175万行挿入 多分 ALTER INDEX ALL ON xxx DISABLE テーブルを切り捨て 175万行挿入 ALTER INDEX ALL ON xxx REBUILD WITH (FILLFACTOR=90) [または類似の何か] どんな支援も感謝します... DBAではなく-DBをかなりよく知っている開発者はより正確です！

10 sql-server  performance  index 

float列の値に基づいてデータを除外するクエリがあります select * from My_Table where my_Float_column != 0 and my_Float_column is not null 私がそれを助けることができるならば、私はフロートタイプにインデックスを付けたくありません。実行プランは、パフォーマンスを向上させるために、以下のようなフィルターされたインデックス（ここでは0とnull値のみをインデックス付けする）を使用するのに十分賢いでしょうか？ CREATE NONCLUSTERED INDEX IX_My_Table_Float_Filtered ON My_Table (my_Float_column) WHERE my_Float_column = 0 or my_Float_column is null

10 sql-server  sql-server-2008-r2  index 

継承したアプリケーションのSQL Serverデータベースを見ています。約10年間SQL Serverを調べていませんので、ご容赦ください。 私が調べているデータベーステーブルにはというbigint NOT NULL列がありますがid、制約を確認しても何も表示されず、すべてのデータベーステーブルに同じことが当てはまります。 これらのテーブルに主キーとインデックス（クラスター化または非クラスター化）がないと仮定しても正しいですか？ 私は次のクエリを実行しましたが、結果は私の疑いを裏付けるように見えます。 //**returns 0** select count(*) from INFORMATION_SCHEMA.TABLE_CONSTRAINTS; //**returns no rows** select * from sys.indexes where object_id = (select object_id from sys.objects where name = 'NAME-OF-TABLE'); //**returns all tables in database** SELECT name FROM sys.tables WHERE OBJECTPROPERTY(object_id,'IsIndexed') = 0;

10 sql-server  index  primary-key  constraint 

VARCHAR最大3071文字を保持できる列を含むInnoDBテーブルを作成しようとしています。UNIQUEこの列のデータに制約を課したいのですが。 MySQLはインデックスを使用して制約を強制しているようです。InnoDBでは、インデックスサイズは767バイトに制限されているように見えます- VARCHAR(3071)データを保持している列には十分ではありません。 最大データ長やInnoDBの使用に妥協することなく、データベースにデータの一意性を強制する方法についての考えはありますか？

10 mysql  index  innodb  constraint 

エンティティ関係図では、インデックスはどのように見えますか？ 私はそれをグーグルで調べました、そしてERDでインデックスの標準的な外観が何であるかわかりません。そして、私はすべてのフィールドを含むcrowsfootダイアグラムについて話している。

10 index  clustered-index  erd  nonclustered-index 

私が持っているSQL Server 2017テストデータベースで意図的に不良インデックス条件を作成したいのですが、これらのメンテナンススクリプトをよりよく理解するためですか？SQL Serverのインデックスと統計のメンテナンス インデックスの整合性を損なったり、インデックスの断片化を増やしたりする高速/自動の方法はありますか？これを達成するために私が調べることができる有用なリソースを知っていますか？

9 sql-server  index  clustered-index