8


6

SQL Server 2005にクラスター化インデックスを持たない理由

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

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

テーブルごとにクラスター化インデックスを1つだけ持つことができ、検索などのクエリパフォーマンスのために非プライマリキー列にクラスター化インデックスを設定することをお勧めします。 ただし、問題のテーブルには他の「CLUSTERED」インデックスはありません。

私の質問は、上記以外に主キー列にクラスタ化インデックスを作成しない技術的な理由があるかどうかです

5 Answer


8


「通常の」データまたはルックアップテーブルについて:いいえ、理由はまったくありません。

一括インポートテーブルや一時テーブルのようなもの-それは依存します。

一部の人々にとっては、驚くべきことに、*良い*クラスター化インデックスを作成すると、実際にはINSERTやUPDATEなどの操作を高速化できるようです。 Kimberly Trippsの優れたhttp://sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-Continues.aspx[The Clustered Index Debate continue …​これが事実です。

この観点から、SQL Serverテーブルに適切なクラスター化インデックス(最も明確な選択肢として、狭い、安定した、一意の、常に増加する=「INT IDENTITY」)が存在する*有効*な理由はありません。

クラスタリングキーを選択する方法と理由に関する深い洞察を得るには、このトピックに関するKimberly Trippの優れたブログ投稿をすべて読んでください。

「インデックス作成の女王」からの素晴らしいもの! :-)


6


http://www.mssqltips.com/tip.asp?tip=1254 [クラスター化テーブルとヒープテーブル]

(http://www.mssqltips.com/tip.asp?tip=1254[www.mssqltips.com]の件名に関する良い記事)

  • HEAPテーブル(クラスター化インデックスなし)*

  • データは特定の順序で保存されません

  • 特定のデータをすぐに取得することはできません 非クラスター化インデックス

  • データページはリンクされていないため、シーケンシャルアクセスは再び参照する必要があります インデックス割り当てマップ(IAM)ページ

  • クラスタ化インデックスがないため、追加の時間は不要です インデックスを維持する

  • クラスタ化インデックスがないため、次の必要はありません。 クラスター化インデックスツリーを格納するための追加スペース

  • これらのテーブルのsys.indexesカタログのindex_id値は0です。 view

クラスタ化されたテーブル

  • データはクラスター化インデックスキーに基づいた順序で保存されます

  • クラスター化インデックスキーに基づいて、データをすばやく取得できます。 クエリはインデックス列を使用します

  • データページは、より高速な順次アクセスのためにリンクされています INSERTS、UPDATES、およびDELETESに基づくクラスター化インデックスを維持するために必要

  • クラスター化インデックスツリーを格納するには、追加のスペースが必要ですこれらのテーブル sys.indexesカタログビューでindex_id値が1になっている


1


最初に、「_クラスタ化されたテーブルのデータ行に直接アクセスできない-なぜですか?」_の下で私の答えを読んでください。 特にアイテム[2]警告。

「データベース」を作成した人はクレチンです。 彼らが持っていた:

  • 正規化されたリレーショナルテーブルではなく、非正規化されたスプレッドシートの束

  • PKは_all_ IDENTITY列です(スプレッドシートは お互い;それらは1つずつナビゲートする必要があります);データベース全体にリレーショナルアクセスやリレーショナルパワーがない

  • 一意のクラスター化を生成するプライマリキーがありました

  • 彼らはそれが並行性を妨げることを発見した

  • CIを削除し、すべてNCIにしました

  • 彼らは面倒で、逆転を終えることができませんでした。代替を指名する (現在のNCI)_各CIの新しいCIになる

  • IDENTITY列は主キーのままです(実際にはそうではありませんが、 この障害のある実装にあります)

このようなデータベースを装ったスプレッドシートのコレクションでは、CIを完全に回避し、NCIとヒープのみを使用することがますます一般的になってきています。 明らかに、彼らはCIの力や利点をまったく得ていませんが、地獄、彼らはリレーショナルデータベースの力や利益をまったく得ていないので、だれがCI(リレーショナルデータベースのために設計された、ではありません)。 彼らがそれを見る方法、彼らはとにかく頻繁にくたびれたものを「リファクタリング」しなければならないので、なぜわざわざ。 リレーショナルデータベースは「リファクタリング」を必要としません。

この応答についてさらに議論する必要がある場合は、CREATE TABLE / INDEX DDLを投稿してください。それ以外の場合は、時間の無駄になる学問的議論です。


0


考えられる別の理由(まだ理解されていない)があります(他の回答で既に提供されていますか?):

私は後で更新することを望みますが、今のところはこれらのトピックをリンクしたいという願望です


0


現在も使用されている一部のBツリーサーバー/プログラミング言語では、固定長または可変長のフラットASCIIファイルがデータの保存に使用されます。 新しいデータレコード/行がファイル(テーブル)に追加されると、レコードは(1)ファイルの最後に追加され(または削除されたレコードを置き換え)、(2)インデックスがバランスされます。 この方法でデータを保存する場合、システムのパフォーマンスを気にする必要はありません(最初のデータレコードへのポインターを返すためにBツリーサーバーが実行している限り)。 応答時間は、インデックスファイルのノード数によってのみ影響を受けます。

SQLの使用を開始すると、SQLステートメントを記述するときは常にシステムパフォーマンスを考慮する必要があることに気付くようになります。 インデックスのない列で「ORDER BY」ステートメントを使用すると、システムがひどくなる可能性があります。 クラスタ化インデックスを使用すると、CPUに不要な負荷がかかる場合があります。 21世紀であり、SQLでプログラミングする際にシステムのパフォーマンスを考慮する必要がなかったらいいのにと思いますが、それでもまだです。

一部の古いプログラミング言語では、ソートされたデータが取得されるたびにインデックスを使用することが必須でした。 私は、この要件が今日もまだ有効であることを願っています。 インデックス化されていないデータに対するSQLステートメントの記述が不十分であるために、低速のコンピューターシステムを更新している企業がどれだけあるのかと思うだけです。

私の25年間のプログラミングでは、特定の順序で物理データを保存する必要がなかったため、一部のプログラマーはクラスター化インデックスの使用を避けています。 特に設計中のシステムがいつか何百万ものレコードを保存する場合、トレードオフが何であるか(ストレージ時間、検索時間)を知ることは困難です。