問題タブ [clustered-index]

SQL 2000
NEDテーブルにはSIGNテーブルへの外部キーがありますNED.RowID
からSIGN.RowIDSIGNテーブルにはNEDテーブルへの外部キーがありますSIGN.SignIDからNED.SignIDRowID
とSignIDは、GUIDであるクラスター化された主キーです（私の選択ではありません）
WHERE句は次のとおりです。

このクエリのSIGNテーブルにINDEXSCANがあるのはなぜですか？クラスタ化されたインデックスでインデックススキャンが発生する原因は何ですか？ありがとう

NDBストレージエンジンを使用してテーブルを作成しようとすると、次のエラーが発生します。

この変数のサイズを変更するにはどうすればよいですか？これがどこに保存または設定されているのかわかりません。

私はDBに触れる機会が限られており、アプリケーションプログラマーとしてDBを使用しただけです。Clusteredとについて知りたいNon clustered indexes。私はグーグルで検索しました、そして私が見つけたものは：

クラスタ化インデックスは、テーブル内のレコードが物理的に格納される方法を並べ替える特殊なタイプのインデックスです。したがって、テーブルに含めることができるクラスター化インデックスは1つだけです。クラスタ化されたインデックスのリーフノードには、データページが含まれています。非クラスター化インデックスは、インデックスの論理的な順序がディスク上の行の物理的に格納された順序と一致しない特殊なタイプのインデックスです。非クラスター化インデックスのリーフノードは、データページで構成されていません。代わりに、リーフノードにはインデックス行が含まれています。

SOで見つけたのは、クラスター化されたインデックスとクラスター化されていないインデックスの違いは何ですか？。

誰かがこれを平易な英語で説明できますか？

SQL Server 2008 を使用しています。テーブルにクラスター化インデックスがない場合はヒープと呼ばれ、それ以外の場合はストレージ モデルがクラスター化インデックス (B ツリー) と呼ばれます。

ヒープ ストレージの正確な意味、外観、「ヒープ」データ構造 (最小ヒープ、最大ヒープなど) として編成されているかどうかについて詳しく知りたいです。おすすめの読み物は？もう少し内部構造を知りたいのですが、深すぎません。:-)

前もって感謝します、ジョージ

Fluent-NHibernate (自動マッピング付き) を使用してテーブルを生成していますが、デフォルトで使用される ID フィールドとは異なるクラスター化インデックスを選択したいと考えています。Fluent NHibernate を使用して、デフォルトの主キー フィールド以外のフィールドにクラスター化インデックスを作成するにはどうすればよいですか?

この背後にある主な理由は単純です。主キー フィールドに Guid を使用しています。デフォルトでは、NHibernate は主キー フィールドにクラスター化インデックスを作成します。通常、Guid は連続していないため、主キー フィールドでクラスタリングを行うとパフォーマンスの問題が発生します。

ご存知のように、テーブルの最後にレコードを追加する方が、テーブル内にレコードを挿入するよりもはるかに安価な操作です。また、テーブル内のレコードは、クラスター化インデックス内のアイテムの順序で物理的に格納されます。Guid はいくぶん「ランダム」であり、シーケンシャルではないため、テーブルに既に存在する他の Id Guid の値よりも小さい新しい Guid が生成される場合があります。その結果、追加ではなくテーブルの挿入が行われます。

これを最小限に抑えるために、DateTime 型の CreatedOn という列があります。すべての新しいレコードが挿入されるのではなく追加されるように、この CreatedOn 列でテーブルをクラスター化する必要があります。

これを達成する方法についてのアイデアは大歓迎です!!!

注: Sequential Guid を使用できることはわかっていますが、セキュリティ上の理由から、そのパスをたどりたくありません。

注: この投稿に対する回答はまだありませんが、現時点で考えているアイデアがいくつかあります。

1. Fluent なしで NHibernate を使用すると、クラスター化されたインデックスを NHibernate で直接作成できる可能性があると思います。これを行う方法を知るには、NHibernate についてまだ十分に知りません。私はかなり（ほぼ絶対に）それができると確信しています。

2. Fluent-NHibernate には、最近の書き直しの前に、SQL オブジェクトに属性 (クラスター化インデックスなど) を設定する方法が含まれていました。現在、そのオプションはなくなっているようです。そのオプションがまだ利用可能かどうかを確認するために、おそらくどこかに質問を投稿します。もしそうなら、おそらくそれを使用してクラスター化インデックスを設定できます。

3. Fluent-NHibernate は、構成が流暢に構築されたら、手動編集用に構成を公開する機能を提供します。この機能を試したことはありませんが、クラスター化インデックスを設定するために必要なレベルの粒度が提供される可能性があると期待しています。

4. 最悪のシナリオでは、生成されたすべてのテーブルのクラスター化インデックスを変更する SQL スクリプトを作成できます。ただし、このアプローチに関していくつか質問があります。A. 自動スキーマ生成を使用しているため、NHibernate は次に構成を評価するときにクラスター化インデックスの変更を「元に戻す」ことはできますか? 2. クラスタ化インデックスが変更されたことを検出した場合、NHibernate はエラーになりますか? これをテストする必要がありますが、まだ行っていません。しかし、私はこのソリューションが本当に嫌いです。SQLServer2008 および MySQL に対して DB をテストしています。NHibernate の優れた点の 1 つは、データベースに依存しないことです。スクリプトを導入すると、すべての賭けがオフになります。

5. このインターフェイスから継承する IPropertyInstance クラスには、フィールドにインデックスを作成できるようにする Index プロパティがあります。問題は、クラスター化されたインデックスを作成できるようにするフラグやその他のオプションがないことです。最も簡単な解決策は、このメソッドにプロパティを追加して、クラスター化インデックスを作成できるようにすることです。これを Fluent-NHibernate 開発者に提案できると思います。

SQL Server に、通常の pk インデックスを 2 つのフィールドのクラスター化インデックスに置き換える必要があるテーブルがあります。これらの他のフィールドは、主キーの一部ではありません。

Oracleでも同様のことをする必要があります。私の知る限り、これはインデックス順のテーブルを使用して実行できますが、これらのインデックスは主キーでのみ構築されると思います。

Oracle で SQLServer のクラスター化インデックスと同様の動作を得る方法はありますか?

SQL Server 2005にストアドプロシージャがあり、それを実行して実行プランを見ると、クラスター化インデックススキャンを実行していることがわかります。これには、84％のコストがかかります。Clustered Index Seekを取得するには、いくつか変更する必要があることを読みましたが、何を変更すればよいかわかりません。

私はこれでどんな助けにも感謝します。

ありがとう、

ブライアン

SQL、特に SQL 2005 のキー、インデックス、および制約について一連の質問があります。私は約 4 年間 SQL を使用してきましたが、このトピックについて決定的な回答を得ることができたことがなく、ブログ投稿などには常に矛盾する情報があります。私が作成して使用するほとんどの時間テーブルには、Identity 列があります。は主キーであり、他のテーブルは外部キーを介してそれを指しています。

結合テーブルでは、ID がなく、外部キー列に対して複合主キーを作成します。以下は、私の現在の信念の一連のステートメントです。間違っている可能性があります。間違っている場合は修正してください。その他の質問.

だからここに行きます：

私が理解しているように、クラスター化インデックスと非クラスター化インデックスの違い (一意であるかどうかに関係なく) は、クラスター化インデックスがテーブル内のデータの物理的な順序に影響を与えることです (したがって、テーブルには 1 つしか存在できません)。非クラスター化インデックスは、ツリー データ構造を構築します。インデックスを作成するとき、クラスター化と非クラスター化を気にする必要があるのはなぜですか? いつどちらを使用する必要がありますか? ツリーを「再構築」する必要があるため、非クラスター化インデックスでは挿入と削除が遅いと言われました。クラスター化されたインデックスは、このようにパフォーマンスに影響しないと思いますか?

主キーは実際には一意のクラスター化されたインデックスにすぎないことがわかります (クラスター化する必要がありますか?)。主キーとクラスター化された一意のインデックスの違いは何ですか?

制約も見たことがありますが、実際に使用したり、実際に見たりしたことはありません。Constraints の目的はデータの整合性を強化することであるのに対し、Index はパフォーマンスを目的としているとのことでした。また、制約は実際にはインデックスとして実装されているため、「同じ」であることも読みました。これは私には正しく聞こえません。制約はインデックスとどう違うのですか?

複数のフィールドを持つクラスター化インデックスでは機能しないという命令が表示されるアプリケーションがあります。テストに抵抗できませんでした、そしてそれは本当です。2つのフィールドを持つクラスター化インデックスを追加すると、アプリは無限のループでスタックします。

インデックスは、アプリケーションに影響を与えないデータベース内部のものだと思いました。クラスタ化インデックスの存在下では機能しないSQLをどのように記述しますか？

アプリはSQLServer2005を使用しています

次の複合クラスター化インデックスを検討してください。

明らかに、 bに個別のインデックスを使用すると、 bの特定の値の検索が高速になります。

ただし、bの個別のインデックスが使用されていない場合でも、 aの離散値のツリーをトラバースして、テーブル スキャンの代わりにbの特定の値を持つタプルを見つけるために複合インデックスを使用できるように思えます。bのローカル検索、aの次の値へのジャンプなど。

これが SQL Server のしくみですか? (たとえば、MSSQL が複数の列を持つインデックスに単一のハッシュ値を使用する場合はそうではありません。)

それはそうであり、他の理由で複合インデックスがすでに必要であり、aの離散値の数が十分に少ない場合、パフォーマンス/スペースのトレードオフは、 bの個別のインデックスを持つことから遠ざかる可能性があります。

(上記の UNIQUE および CLUSTERED 制約は、この例では実際には必要ありませんが、 bの個別のインデックスを含まないbの最速の取得を表します -- 前者はaの各ループのショートカットを提供し、後者は削除しますルックアップでの 1 度の間接参照)。