問題タブ [clustered-index]

H2 で次のテーブルを作成します。

次に、INFORMATION_SCHEMA.TABLES テーブルを調べます。

結果：

次に、INFORMATION_SCHEMA.CONSTRAINTS テーブルを調べます。

結果：

これらのステートメントは私が述べたものではありません。したがって、質問は次のとおりです。TABLES と CONSTRAINS の情報は、データベースで実行された実際の SQL をどのように反映していますか?

1. 元の CREATE TABLE ステートメントには、CACHEDという単語はありませんでした。（問題ない）
2. ALTER TABLE .. ADD CONSTRAINTステートメントを実行したことがありません。

私が質問をしている実際の理由は、主キーがクラスター化インデックスで使用されることを保証するためにどのステートメントを実行すればよいかわからないためです。私の以前の質問H2 database: clustered index supportを見ると、Thomas Mueller の回答に次のステートメントが見つかるかもしれません。

テーブルの作成後に主キーが作成された場合、主キーは新しいインデックス B ツリーに格納されます。

したがって、INFORMATION_SCHEMA に示されているようにステートメントを実行すると、テーブルの作成後に主キーが作成されるため、ID はクラスター化インデックスで (基本的にデータ B ツリーのキーとして) 使用されません。

H2 のクラスター化インデックスで主キーが使用されていることを保証する方法はありますか?

それに似た注釈付きクラスを作成したい：

このクラスでは、クラスター化インデックスとして Id 列を作成したいと考えています。注釈や休止状態でそのようなことは可能ですか?

IMO、訂正してください...
クラスター化インデックスのリーフには実際のテーブル行が含まれているため、中間リーフを含む完全なクラスター化インデックスには、完全なテーブルよりもはるかに多くのデータが含まれます（？
）全表スキャンよりも選択されましたか？

SELECTリストまたはWHERE条件[1]のいずれにも含まれていないSELECTクエリでCUSTOMER_ID列のクラスター化インデックスはどのように使用されますか？

更新：
「各データページには次および前のリーフノードページへのポインターが含まれているため、スキャンでインデックス内の上位レベルのページを使用する必要がない」ため、全表スキャンよりも全表スキャンの方が高速であることを理解する必要がありますか？
（クエリに参加しない）クラスター化されたインデックスが並べ替えに使用されるなど、他の理由はありますか？

Update2：
後から考える と、IAMポインターを介したテーブルのロードを並列化できる間、連続アクセスではパフォーマンスを向上させることはできません。
クラスター化されたインデックススキャンは、連続したページ読み取りを意味しますか？
クラスタ化されたテーブルは、IAMポインタがないことを意味しますか（全表スキャンの不可能性）？
クラスタ化されたテーブルを完全なテーブルスキャンできないのはなぜですか？
クラスター化インデックスのフルスキャンがフルテーブルスキャンよりも「優れている」方法/理由をまだ理解していません。
クラスター化されたインデックスがあると、パフォーマンスが低下する可能性があるということですか？

問題は、ヒープ（インデックス付けされていない）テーブルではなく、クラスター化されたテーブルに関するものです。

Update3：
「フルクラスター化インデックススキャン」は本当に「フルテーブルスキャン」と同義ですか？
違いは何ですか？

[1]インデックスカバーによりSQLServerクエリのパフォーマンスが向上
http://www.devx.com/dbzone/Article/29530

SQL SERVER 2005 データベース用のデータベース作成スクリプトをいくつか継承しました。

私が気づいたことの 1 つは、すべての主キーがNON CLUSTEREDクラスター化ではなくインデックスとして作成されることです。

テーブルごとにクラスター化インデックスを 1 つしか持つことができず、検索のクエリ パフォーマンスなどのために非主キー列にクラスター化インデックスを配置したい場合があることはわかっています。ただしCLUSTERED、問題のテーブルには他のインデックスはありません。

したがって、私の質問は、上記とは別に、主キー列にクラスター化インデックスを持たない技術的な理由はありますか?

私は SQL にかなり慣れていないので、おそらくインデックスの使用を改善することによって、postgres で複雑な SQL クエリを高速化する方法を考え出そうとしています。これはクエリです：

これは基本的にデータベーススキーマです (Pylons で定義されています):

また、次のようなインデックスがあります。

クエリを高速化する明らかなインデックスがありませんか? 特に：

• 「クラスター化」インデックスを使用する必要がありますか?
• にもインデックスamountを作成する必要がありますentryか、それとも違いはありませSUM(t.amount) as amountんか?

ご協力いただきありがとうございます。これはかなり複雑な質問であることは承知していますので、改善するために何かできることがあれば教えてください。

- - - アップデート - - - - - - -

上記のクエリのEXPLAIN ANALYZE からの出力。

「単純な選択クエリの応答時間を短縮するにはどうすればよいですか?」という質問へのコメント 教えて：

• 「LaunchDate のデータ型は何ですか? DATETIME または DATETIME2 の場合、時間部分が含まれているため、インデックスはあまり機能しない可能性があります – OMG Ponies」

• 「@OMG - DateTime 列のクラスター化インデックスがパフォーマンスを向上させないのはなぜですか?クエリは範囲スキャンであり、すべてのデータが順次ブロックにあるため、高速範囲インデックス検索が可能になりますか?準関連... msdn. microsoft.com/en-us/library/ms177416.aspx – カルガリー コーダー"

• 「カルガリー コーダー: DATETIME/2 には時間が含まれます。クラスター化または非クラスター化されたインデックスは、時間は重複するが範囲ではない日付に適しています。 – OMG Ponies」

DATETIMEタイプ列にクラスター化インデックスを使用してテスト テーブルを作成しLaunchDate、上記の質問で引用したようなクエリのインデックス シークを観察しました。

テーブルまたはインデックスのスキャンの代わりに。

列のクラスター化インデックスがDateTimeパフォーマンスを向上させないのはなぜですか? 時間部分が含まれている場合、または時間が含まれているため、
インデックスがあまり機能しないのはなぜですか?DATETIMEDATETIME2

DATETIME列のインデックスを作成してもパフォーマンスが向上しないこと を示すスクリプトをいただければ幸いです。

更新: また、OMG はDATEtype 列のインデックスが役立つことを暗示していましたが、そうではDATETIMEありませんでしたDATETIME2か?

私はSQLServer2005の初心者であり、オンラインチュートリアルから学んでいます。ここに、私の質問の一部を示します。

1：[XYZから*を選択]と[XYZからすべて*を選択]の違いは何ですか。

2：クラスター化インデックスの目的は、テーブルを物理的にソートすることで検索を容易にすることです[私が知る限り:-)]。テーブルにプライマリ列がある場合、テーブルにクラスター化インデックスを作成するのが適切であるとしましょう。ソートされた列がすでにあるためです。

3：テーブルに1つのクラスター化インデックス+249の非クラスター化インデックス=250のインデックスを作成できるのはなぜですか？1つのクラスター化されたインデックスの要件を理解しています。しかし、なぜ249 ?? なぜ249以下ですか？

クラスタ化されたインデックスが一意でない場合はどうなりますか？挿入された行が何らかの「オーバーフロー」ページに流れるため、パフォーマンスが低下する可能性がありますか？

それは「作られた」ユニークなものですか？もしそうなら、どのように？それをユニークにするための最良の方法は何ですか？

現在、クラスター化インデックスを使用してテーブルを論理部分に分割しているので質問していますが、パフォーマンスはまあまあで、最近、クラスター化インデックスを一意にするようアドバイスを受けました。それについてセカンドオピニオンをお願いします。

SQL Serverデータベースに、「一般的な」使用規則に従わないかなり一意のテーブルがあり、クラスター化インデックスに関するアドバイスを探しています。

これは作り上げられた例ですが、実際のデータにかなり厳密に従っています。

このテーブルには、他のテーブルへの実際の外部キーである3列の主キーと、関連データを含む4番目のフィールドがあります。この例では、テーブルが次のようになっているとしましょう。

したがって、4番目のフィールドが一意のデータである、やや階層的な主キーがあります。

実際のアプリケーションでは、合計28億の可能なレコードがありますが、それだけです。データは時間の経過とともに計算されるため、レコードはその場で作成されます。現実的には、これらのレコードの1/4だけが実際に計算される可能性があります。計算はコストのかかる操作であり、一意の組み合わせごとに1回だけ実行するため、これらはDBに保存されます。

現在、データは1分間に数千回読み取られますが、（少なくとも今のところ）テーブルが自動的に読み込まれるため、1分間に数百の挿入があります（これはかなりの時間続きます）。（今日）挿入ごとに10回の読み取りがあると言えます。

クラスター化されたインデックスのために、これらすべての挿入でパフォーマンスが低下しているのではないかと思います。

クラスター化インデックスは、テーブルが最終的に読み取り専用になるため、「長期的」に意味がありますが、そこに到達するには時間がかかります。

大量の挿入期間中にインデックスを非クラスター化し、テーブルにデータが入力されるとクラスター化に変更できると思いますが、クロスオーバーポイントがいつになるかをどのように決定しますか（そして将来どのように通知できますか） 「時が来た」）？

私が本当に必要としているのは、将来の魔法の時期に非クラスター化からクラスター化に移行するコンバーチブルインデックスです。

これを処理する方法について何か提案はありますか？

私は最近、すべてのテーブルをヒープ インデックスの使用から変換して、各テーブルにクラスター化されたインデックスが含まれるようにする必要があるというアドバイスを受けました。この戦略を実行すると、どのような結果が得られますか? たとえば、データベースを定期的に再編成することがより重要ですか? データの増加？本当に遅い挿入の危険性? PK が GUID の場合、ページ最適化の危険性はありますか? アプリケーションの顕著な速度向上? あなたの経験は何ですか？

良い答えのインスピレーションとして役立つように、stackoverflow の他のスレッドから拾った「事実」の一部を次に示します。

1. ほぼ確実に、データベース内のすべてのテーブルにクラスター化インデックスを作成したいと考えています。テーブルにテーブルがない場合。最も一般的なクエリのパフォーマンスが向上します。
2. クラスター化されたインデックスは、GUID では常に悪いわけではありません...それはすべて、アプリケーションのニーズに依存します。INSERT 速度は低下しますが、SELECT 速度は向上します。
3. GUID フィールドのクラスター化インデックスの問題は、GUID がランダムであるため、新しいレコードが挿入されると、テーブルの中央にレコードを挿入するためにディスク上のデータの大部分を移動する必要があることです。
4. GUID のクラスター化インデックスは、GUID に意味があり、関連データを互いに近くに配置することでパフォーマンスが向上する状況では問題ありません http://randommadness.blogspot.com/2008/07/guids-and-clustered-indexes.html
5. クラスタリングは検索速度に影響しません。一意の非クラスタ化インデックスがその役割を果たします。