問題タブ [clustered-index]

SQL では、何百万ものレコード (Transactios テーブルの CustomerID など) を検索するときはいつでも、CustomerID のインデックスを追加する必要があることは明らかです。

フィールドを基準として使用して内部結合または外部結合を行う必要がある場合に、フィールドにインデックスを追加したい別の状況はありますか? t1.customerID = t2.customerID の内部結合など。次に、両方のテーブルの customerID にインデックスがない場合は、2 つのテーブルを順番にループする必要があるため、O(n^2) を調べています。両方のテーブルの customerID にインデックスがある場合、O( (log n) ^ 2 ) になり、はるかに高速になります。

テーブル内のフィールドにインデックスを追加したい状況は他にありますか?

テーブルに結合された 2 つのフィールドにインデックスを追加するのはどうですか。つまり、2 つのフィールドを合わせて 1 つのインデックスですか?

SQLServer2005のクラスター化インデックスとは何かを理解するのに苦労しています。私はMSDNの記事ClusteredIndexStructures（とりわけ）を読みましたが、それを正しく理解しているかどうかはまだわかりません。

（主な）質問は次のとおりです。クラスター化インデックスのあるテーブルに（「low」キーを使用して）行を挿入するとどうなりますか？

上記のMSDNの記事には次のように記載されています。

データチェーン内のページとその中の行は、クラスター化インデックスキーの値に基づいて並べ替えられます。

たとえば、クラスター化インデックスを使用すると、次のようになります。

たとえば、順番に並べられたリストの先頭に近いテーブルにレコードが追加された場合、そのレコードの後のテーブル内のレコードは、レコードを挿入できるようにシフトする必要があります。

これは、非常に「低い」キーの行を、すでに数十億行が含まれているテーブルに挿入すると、文字通りすべての行がディスク上で物理的にシフトされることを意味しますか？信じられない。これには何年もかかりますね

それとも（私が思うに）最初のデータページがどれだけ「いっぱい」であるかに応じて2つのシナリオがあるのではないでしょうか。

• A）ページにレコードを収容するのに十分な空き領域がある場合、そのページは既存のデータページに配置され、データはそのページ内で（物理的に）並べ替えられる可能性があります。
• B）ページにレコード用の十分な空き領域がない場合、新しいデータページが作成され（ディスク上のどこかに！）、Bツリーのリーフレベルの前面に「リンク」されますか？

これは、データの「物理的な順序」が「ページレベル」（つまり、データページ内）に制限されるが、物理ハードドライブ上の連続するブロックにあるページには制限されないことを意味します。次に、データページが正しい順序でリンクされます。

または、別の方法で定式化されます。SQLServerがクラスター化インデックスを持つテーブルの最初のN行を読み取る必要がある場合、データページを順番に（リンクをたどって）読み取ることができますが、これらのページは（必然的に）ディスク上で順番にブロックされません。（したがって、ディスクヘッドは「ランダムに」移動する必要があります）。

私はどれくらい近いですか？:)

主キー (int) にクラスター化インデックスを持つテーブルがある場合、非クラスター化インデックスの列の 1 つとしてその主キー列を含む 1 つ (または複数) の非クラスター化インデックスを持つことは冗長であり、悪いことですか? ?

SQL Server 2005 (クラスター化) に対して動作する .NET クライアント アプリがあります。クライアント アプリをクラスター対応にするために何か特別なことを行う必要がありますか?

私はデータベース システムに取り組んでおり、それはインデックスですが、カバリング インデックスとクラスター化インデックスの明確な違いを理解するのに非常に苦労しています。

私は自分の道をグーグルで検索しましたが、明確な答えがありません:

1. 2 種類のインデックスの違いは何ですか
2. いつカバリング インデックスを使用し、いつクラスター化インデックスを使用しますか。

誰かがほとんど子供のような答えで私に説明してくれることを願っています:-)

メスティカ

ちなみに、IBM DB2 バージョン 9.7 を使用しています。

データベースでいくつかのクエリを実行していて、パフォーマンスを向上させたいと考えており、いくつかのインデックスを作成しましたが、それでも応答時間が長すぎると思うので、速度を上げるために、より良いインデックスまたは別のインデックスを作成できるかどうかを確認したいと考えています。

私が考えるテーブルのスキーマには、次のような最大のボトルネックがあると思います。

興味深いのは、日付 (例: 2010-05-20) を含むSDD属性で、私のクエリでは次のような範囲検索を行います: SDD >= '2010-05-03' and SDD < '2010-05-08'

私が持っている、実際にパフォーマンスを向上させるインデックスは、

問題は、2010-05-03 と 2010-06-04 のように距離の長い範囲検索を行うと、クエリの実行に約 6 ～ 10 秒かかることです。

SDD でいくつかのインデックスとクラスター インデックスを試してみましたが、これまでのところ、上記のインデックスが最良の結果でした。

アドバイスをいただければ幸いです。

心から

メスティカ

この質問は、挿入が行われたときにクラスター化インデックス内のデータの再編成で何が起こるかに関するものです。クラスター化インデックス内のデータを再編成するには、ディスク上のデータの物理レイアウトを変更する必要があるため、クラスター化インデックスを使用しないテーブルよりも、クラスター化インデックスを使用するテーブルで挿入を行う方がコストがかかると思います。仕事で出くわした例を除いて、私の質問をどのように表現すればよいかわかりません。

テーブル (ジャンク) があり、テーブルに対して実行される 2 つのクエリがあるとします。最初のクエリは名前で検索し、2 番目のクエリは名前と何かで検索します。データベースで作業していると、次のように、各クエリをサポートするために 1 つずつ、2 つのインデックスでテーブルが作成されていることがわかりました。

2 つのインデックスを調べたところ、IX_Name_Something は名前で検索する任意のクエリで使用できるため、IX_Name は冗長であるように見えます。したがって、IX_Name を削除し、代わりに IX_Name_Something をクラスター化インデックスにします。

より効率的な挿入/削除が行われるため、最初のインデックス作成スキームを維持する必要があると誰かが提案しました (名前と何かの更新について心配する必要はないと仮定します)。それは理にかなっていますか？維持する必要があるインデックスが 1 つ少ないことを意味するため、2 番目のインデックス作成方法の方が優れていると思います。

この特定の例についての洞察や、クラスター化インデックスのメンテナンスに関する詳細情報を教えていただければ幸いです。

質屋アプリケーション (任意の RDBMS):

各顧客 (マスター) が多くのトランザクション (詳細) を持つことができる 1 対多の関係。

何人かの人々が、これは master を詳細に結合する正しい方法ではないと私に言いました。彼らは、私は常に customer.id[serial] を transactions.id[integer] に結合するべきだと言いました。

顧客が商品をポーンすると、店員は名前にワイルドカードを使用してマスターに問い合わせます。クエリは通常、複数の顧客を返します。事務員は適切な名前が見つかるまでスクロールし、'D' を入力して詳細トランザクション テーブルに変更します。すべてのトランザクションが自動的にクエリされ、次に事務員が 'A' を入力して新しいトランザクションを追加します。

transaction.id に結合する customer.id を使用する際の問題は、顧客テーブルがソートされた名前順に維持されているにもかかわらず、トランザクション テーブルを fk_id でクラスタ化すると、トランザクションが fk_id でグループ化されますが、それらは顧客名と同じ順序ではないことです。店員がマスターで顧客名をスクロールしているとき、システムは各顧客に属するクラスター化された取引を見つけるためにあちこちジャンプしなければなりません。新しい顧客が追加されるたびに、次の ID がその顧客に割り当てられますが、新しい顧客はアルファベット順に表示されません。id join を使って実験したところ、パフォーマンスの低下を確認しました。

名前結合と ID 結合を使用することの欠点は、顧客名を変更すると、トランザクションとの結合が切断されるため、名前の更新を許可しないことです。とにかく、どのくらいの頻度で顧客の名前を変更する必要がありますか? もう 1 つの欠点は、id が INT である name には 30 文字が必要であるため、.dat と .idx の方が大きくなることです。毎朝 sql proc が実行され、顧客とトランザクションがソートされた名前順にアンロードされ、テーブルが削除/再作成され、アンロードされたデータがロードされ、すべてのインデックスが再作成されてパフォーマンスが最適化されます。

トランザクションに名前列がない場合、名前結合の代わりに ID 結合を使用し、クラスター化されたトランザクションの順序を名前で保持するにはどうすればよいですか?

以下は、上記のスキーマで説明されているように、pk/fk 名を使用するときにデータが customer.dat および transactions.dat にどのように配置されるかの例です。

そのため、店員が顧客のマスター名でワイルドカード クエリを実行すると、顧客のトランザクションが自動的にクエリされ、現在のリストに返された名前をスクロールすると、顧客のトランザクションがマスターと同じソート順であるため、すばやく表示されます。

次の例は、pk/fk id を使用した同じデータです。

OK、ここで、1 ページの実行画面にはすべての顧客列とすべてのトランザクション列が含まれていることに注意してください。店員が顧客名でクエリを実行すると、その顧客に属する最初のトランザクション行が自動的に表示されるマスター/詳細指示があります。 . 次に、店員は「D」を押して取引をアクティブなテーブルにし、「A」を押して新しい取引を追加します。または、店員はすべての顧客取引をスクロールして特定の取引を更新するか、顧客に情報を提供するだけです。

pk/fk name メソッドを使用する場合、店員が顧客名をスクロールして目的の顧客を見つけると、応答は即座に行われます。一方、pk/fk id メソッドを使用する場合は、サポートされているインデックス作成を使用しても、応答時間が遅くなります。これは、店員が各顧客名をスクロールするときに、各顧客に属する対応するトランザクション グループを見つけるために、エンジンがトランザクション テーブル内のさまざまな場所にジャンプする必要があるためです。マスターで！

したがって、顧客のトランザクション行をグループ化し、顧客行と同じソート順にすることで、各顧客トランザクションの散在するグループ全体をジャンプする必要があるのではなく、インデックス作成でトランザクションをより迅速に見つけることができます。各顧客が自分の顧客 ID 番号を覚えていれば、私の問題は学術的なものになりますが、実際には、各顧客に顧客番号が記載された ID カードを渡しましたが、ほとんどの顧客がカードを紛失しました!

以下は、質屋が営業を開始する前に毎朝実行される毎日の reorg の例です。

時間があれば、誰にでもこれをテストするように挑戦します! .. 大きなテーブルがあると、より顕著になります。

ID ではないプロパティを nhibernate のクラスター化インデックスとして定義しようとしていますが、これを行う方法が見つかりません。

これがどのように行われるか、または現在nhibernateで利用できないものであることを誰かが教えてくれますか?

前もって感謝します

Guid によってテーブルをクエリする場合 (Guid の断片化の問題に関係なく)、Guid をクラスター化されていないインデックスとして使用するか、インデックスをまったく使用しないよりも高速でしょうか?

この質問は、読み取り専用の観点からのものです。特定の Guid の検索行間で速度が向上するかどうか、およびインデックスの有無にかかわらず、またはクラスター化インデックスの有無にかかわらず、検索がより高速に完了するかどうかに興味がありますか?

または、次の質問への回答にはかなり確信がありますが、前の質問に int 識別子を適用します。テーブルがそのintでクラスター化されていると、検索が速くなりますか? (これは、テーブル内の他のアイテムによってクラスター化されているのではなく?)

このトピックには他にも多くの質問が投稿されていることは知っていますが、これらのいずれにも探している特定の回答が見つかりませんでした:
Sequential Guid 主キー列はクラスター化インデックスにする必要がありますか?
クラスター インデックス GUID 主キーのパフォーマンスの向上 インデックスを使用した SQL Server のuniqueidentifier
の一意の識別子 ID 列のクラスター化された主キーGuid 列のクラスター化インデックスを削除する必要があります

助けてくれてありがとう！