問題タブ [clustered-index]

clusteredaと a はどう違いnon-clustered indexますか?

インデックスを使用しないのが最善かどうかについて、いくつか質問があります。

背景：私のレコードにはタイムスタンプ属性があり、レコードはタイムスタンプの順に挿入されます（つまり、時系列で挿入されます）。

質問：

1. インデックスを使用しない場合、データベースはレコードが挿入された順序でレコードを挿入するのが一般的ですか？

2. ＃1の答えが「はい」の場合、「SELECT ..WHEREタイムスタンプ>X」タイプのクエリを実行すると、データベースは効率的になりますか、それともインデックスが作成されていないため、すべてのレコードを処理する必要がありますか？インデックスがない場合、データベースはレコードがソートされた順序で挿入されたことを「認識」しないため、データベースのソートされたプロパティを利用できないと思います。

これらのタイプのレコードとその挿入には、クラスター化されたインデックスが最適であると思います。

皆さんの感想を教えてください。

ありがとう、jbu

通常、GUID を主キーとして使用するデータベースに取り組んでいます。

既定では、SQL Server はクラスター化インデックスを主キー列に配置します。これは GUID 列のばかげた考えであり、非クラスター化インデックスの方が優れていることは理解しています。

どう思いますか? すべてのクラスター化インデックスを取り除き、それらを非クラスター化インデックスに置き換える必要がありますか?

SQL のパフォーマンス チューナーがこれを推奨事項として提供しないのはなぜですか?

最近、データベースのインデックス作成とクラスター化インデックス作成についていくつかの質問がありましたが、ここ数週間までは少し新しいものでした。それがどれほど重要であり、それらを作成することでどのようなパフォーマンスの向上が期待できるのか疑問に思いました。

Edit: What is usually the best type of fields to look at when putting in a clustered index when you are first starting out?

問題のテーブルは、ベンダーのソフトウェアがネットワーク上で使用するデータベースの一部です。テーブルには、ファイルに関するメタデータが含まれています。テーブルのスキーマは次のとおりです。

ResultID と Fieldname にはクラスター化インデックスがあります。通常、このテーブルには数百万行が含まれます (5 億行が含まれる場合もあります)。テーブルは、データが「処理」されているときに、それぞれ 4 つのスレッドを実行する 24 のワーカーによって設定されます。これにより、多くの非順次挿入が発生します。後で処理した後、社内ソフトウェアの一部によって、このテーブルにさらにデータが挿入されます。特定のテーブルの断片化は少なくとも 50% です。最大のテーブルの場合、90% です。DBA はありません。DB の保守戦略が切実に必要であることは承知しています。私の経歴としては、私はこの会社でアルバイトをしている大学生です。

私の質問はこれです.クラスター化インデックスはこれを行うための最良の方法ですか? 別のインデックスを検討する必要がありますか? このタイプおよび同様のアドホック DBA タスクに関する適切なリファレンスはありますか?

多数の行 (10K+) を持つテーブルがあり、主キーは GUID です。主キーはクラスター化されています。このテーブルでは、クエリのパフォーマンスが非常に低くなります。効率化するための提案をお願いします。

分散環境で使用するデータベースインデックスの「ナイーブな」実装を開発する必要があります。私はその主題についてほとんど何も知りません、そして私は時間によって少しプレッシャーを感じています。

このテーマに関するいくつかの意見、例、アルゴリズムを聞きたいです。実装する必要があるものを精神的に表現できるようにしたいと思います。

編集：私はクラスター化インデックスを参照しています

インデックスを持たない (PK さえも持たない) テーブルにデータが物理的にどのように配置されているかを誰かが知っているかどうか知りたいです。この質問では、OP は、クラスター化された PK をドロップするのに長い時間がかかっていると主張しています。クラスタ化インデックスがデータそのものであることはわかっていますが、長い処理時間を説明する新しいデータ配置は何でしょうか?

テーブルの主キーである 2 つの列にクラスター化インデックスを持つテーブルがあります。次のように定義されています。

このクラスター化インデックス PK を削除し、次のようにクラスター化インデックスを追加し、以下に示す非クラスター化インデックスを使用して主キー制約を追加したいと考えています。

PK クラスター化インデックスを削除してから、新しいクラスター化インデックスを追加し、次に非クラスター化主キー インデックスを追加するつもりでしたが、既存のクラスター化インデックスを削除すると、テーブル データの順序が変更されることがわかりました (こちらの回答を参照してください) 。 SQL 2005 でクラスター化された主キーを削除すると発生します)、これは必要ではないと思います。テーブルは 1 TB をノックしているので、不要な並べ替えは避けたいと思っています。

私の質問は、既存の構造から望ましい構造に移行するための最良の方法は何ですか?

編集：明確にしたいだけです。テーブルは 1 TB ですが、残念ながら一時テーブルを作成するスペースがありません。一時テーブルを作成せずにそれを行う方法があれば教えてください。