今日は、MS SQL DBMS インデックスとその内部構造について説明します。 DBMS の観点と 1C 8.3 の観点の両方からインデックスについて話していきたいと思います。

インデックスは、MS SQL DBMS のパフォーマンスを最適化するために作成された、特定の列ごとに順序付けされたリンクのセットです。

インデックスを暗黙的に作成する:

プラットフォームは、各メタデータ オブジェクト (リンク、コード、名前、測定値など) に対して事前に知られているデータ キーを使用してインデックス自体を作成します。

インデックスを明示的に作成する次の 3 つの方法で可能です。

1. フィールド (属性/ディメンション) の「インデックス」フラグを設定します。 オプション「追加のインデックス」 順序付け」は、「コード」フィールドまたは「名前」フィールドをインデックスに追加します（主に ）。
2. 「 」にフィールドを追加します。
3. 「 」構造を使用してクエリ内のインデックス付きフィールドを指定します。

1C の 267 ビデオ レッスンを無料で入手:

Microsoft SQL DBMS のインデックス

MS SQL DBMS のインデックスは、それぞれ 8 KB のデータを含むページです。 インデックスは DBMS のパフォーマンスを向上させるように設計されているにもかかわらず、ディスク領域を占有し、DBMS の行の書き込み処理が遅くなるという欠点もあります。

MS SQL DBMS のインデックスの種類:

1. 非クラスター化インデックス— このようなインデックスはテーブルを再構築せず、リンクを整理するだけです。
2. クラスター化インデックスインデックスに従ってテーブルを構築するために必要です。 データは、たとえばアルファベット順に編成されます。 頻繁に変更される列には無効です。 DBMS は、このインデックスを使用してテーブルを物理的に再構築し続けます。
3. 固有のインデックス- クラスター化インデックスおよび非クラスター化インデックスの一種の「上部構造」。 このようなインデックスは、キー フィールドに基づいて一意です。

DBMS のキーの種類:

• 主キー— 行を一意に特徴付ける列のセット。
• 外部キー（外部）— テーブル間の関係を整理する目的で主キー値を格納するテーブル フィールド。 1C ではこのタイプのキーは使用しません。

インデックスの使用に関する重要なニュアンス

インデックスを適切に使用すると、クエリを数倍だけでなく、数百倍、場合によっては数千倍も高速化できます。

この種の高速化はハードウェアでは実現できません。したがって、このトピックには細心の注意を払う必要があります。

多くの場合、クエリを高速化するには独自のインデックスを作成する必要がありますが、これを行うにはいくつかの異なる方法があります。

ビデオチュートリアルでは、インデックスを作成するいくつかの方法を見ていきます。 また、標準のプラットフォーム ツールを使用して必要な構成のインデックスを作成できず、DBMS で作成する必要がある状況も考慮します。

標準のプラットフォームツールを使用したインデックスの設定

このレッスンでは、DBMS レベルでオブジェクトに対して実際にどのようなインデックスが作成されるかを示します。
このトピックのすべてが一見したほど明白であるわけではありません。 結局のところ、多くのオブジェクトにはインデックスを作成する機能があります。
このビデオですべての詳細を見ていきます。

追加の順序を使用したインデックス作成

ビデオでは、インデックス構築オプションの違いを示しています。 索引から 追加のインデックス 注文する.
この例は、追加の順序付けを使用するときにプラットフォームがどのような種類のインデックスを構築するかを示しています。

レジスタ次元のインデックスの作成

レジスタの最初の次元のインデックス付けには、いくつかのニュアンスがあります。
ビデオでは、レジスタ測定用にどのようなインデックスが作成されるかを示します。 最初のレジスタ次元のインデックス付けの状況も考慮されます。

メタデータにさまざまなオブジェクトの詳細を記述する場合、Index プロパティを設定することができます。 このプロパティを使用すると、構成開発者は、対応する詳細に対してデータベースに別のインデックスを構築する必要があることをシステムに示すことができます。

このプロパティの「インデックス」オプションに加えて、ほとんどのオブジェクトに対して「追加の順序を指定したインデックス」オプションを設定できます。 このオプションは主に動的リストで使用することを目的としています。

「インデックス」オプションでは、詳細に基づいてインデックスが直接作成されます。 インデックスには、属性値が繰り返されるときにインデックス内のレコードの特定の順序を保証するためのリンクも追加されます。

「追加の順序付けによるインデックス」オプションでは、インデックスは属性によって構築されるだけでなく、このタイプのオブジェクトの順序付けに通常使用されるフィールドによっても構築されます。 ディレクトリの場合、メインの表現に応じて、インデックスにコードまたは名前が追加されます。 ドキュメントの場合、インデックスに日付が追加されます。 この索引にはリンクも追加されています。

「インデックス」オプションでは、作成されたインデックスが使用されるため、動的リストにより、この属性による順序で大量の情報を効率的に表示できます。

動的リストの「追加の順序付けによるインデックス」オプションを使用すると、特定の属性の値による選択と、特定のオブジェクトの主な順序に対応する順序付けにより、大量の情報を効果的に表示できます。 この場合、選択を実行する属性とメインの順序付けフィールドを含むインデックスが存在するため、システムはリストを表示するときにインデックスを使用できます。

もちろん、インデックスは情報を取得する他の方法 (オブジェクト マネージャーまたはクエリのメソッドを使用したデータの取得) にも影響します。

したがって、Index プロパティのオプションを決定するときは、情報を取得するためのどのオプションを最初に最適化する必要があるのか​​を検討する必要があります。 たとえば、詳細を選択してリストを表示する必要がある場合は、「追加の順序でインデックスを作成」オプションを使用するのが合理的です。 また、たとえば、順序付けせずに指定された詳細でオブジェクトをクエリする検索のみにインデックスが必要な場合は、作成されたインデックスに必要なシステム リソースが少なくなるように、「インデックス」オプションを使用することをお勧めします。

メタデータ プロパティのさまざまな組み合わせに対してシステムによって生成されるインデックスの構成については、「データベース テーブルのインデックス」の記事で詳しく説明されています。

または

1C 開発者はなぜ、レジスタのディメンションと詳細を「インデックス」する必要があるのでしょうか?

- さて、リクエストがあります！ - データベースはこう言ってハングしました...

タイトルの質問に対する簡単な答えは、これによりクエリを迅速に実行できるようになり、 に対するロックの悪影響が軽減されるということです。

インデックスとは何ですか?

インデックス配置の最適化

テーブルの量によってサーバーの RAM に「収まる」ことができない場合は、ディスク サブシステム (I/O) の速度が優先されます。 そしてここで、異なるハードドライブにある個別のファイルにインデックスを配置する機能に注目することができます。

アクションの詳細な説明 http：//テクネット.マイクロソフト.com/る-る/図書館/MS175905.aspx
別のファイル グループのインデックスを使用すると、I/O プロセスとインデックス自体の作業の同時実行により、非クラスター化インデックスのパフォーマンスが向上します。
寸法を決定するには、上記の処理を使用できます。

ロックに対するインデックスの影響

クエリに必要なインデックスが存在しないということは、すべてのテーブル レコードを反復処理することを意味し、その結果、冗長なロックが発生します。 不要なレコードはブロックされます。 さらに、インデックスの欠落によりクエリの完了に時間がかかるほど、ロックの保持時間も長くなります。
ロックが発生するもう 1 つの理由は、テーブル内のレコードの数が少ないことです。 この点に関して、SQL Server はクエリ実行プランを選択するときにインデックスを使用せず、テーブル全体をクロールし (テーブル スキャン)、テーブル全体をブロックします。 このようなブロッキングを回避するには、テーブル内のレコード数を 1500 ～ 2000 に増やす必要があります。 この場合、テーブルのスキャンのコストが高くなり、SQL Server はインデックスの使用を開始します。 もちろん、これは常に実行できるわけではなく、「組織」、「倉庫」、「部門」などの多数のディレクトリが必要になります。 通常、エントリはほとんどありません。 このような場合、インデックスを作成してもパフォーマンスは向上しません。

インデックスのパフォーマンス

記事のタイトルで、クエリのパフォーマンスに対するインデックスの影響に興味があることをすでに述べました。 したがって、インデックスは次のタイプのタスクに最適です。

• 「狭い」検索条件を指定するクエリ。このようなクエリでは、特定の基準を満たす少数の行のみを読み取る必要があります。
• 値の範囲を指定するクエリ。これらのクエリでは、少数の行を読み取る必要もあります。
• リンク操作で使用される検索。バインド キーとしてよく使用される列は、インデックスに最適です。
• データを特定の順序で読み取る検索。結果セットがクラスター化インデックス順に並べ替えられる場合、結果セットはすでに事前に並べ替えられているため、並べ替えの必要はありません。 たとえば、クラスタ化インデックスが列 lastname、firstname に作成されており、アプリケーションで姓、名による並べ替えが必要な場合は、ORDER BY 句を追加する必要はありません。

確かに、インデックスにはさまざまな利点がありますが、非常に重要な点が 1 つあります。それは、インデックスが「効率的に使用」され、より少ない I/O 操作とシステム リソースの量でデータを検索できるようにする必要があるということです。 逆に、未使用 (めったに使用されない) インデックスは、データ書き込みパフォーマンスを低下させ (データを変更するすべての操作でインデックス ページも更新する必要があるため)、過剰なデータベース領域を作成する可能性が高くなります。

カバーリング(特定のリクエストの) は、このリクエストに必要なフィールドをすべて含むインデックスと呼ばれます。 たとえば、列 a、b、および c にインデックスが作成され、SELECT ステートメントがこれらの列のみのデータをクエリする場合、必要なのはインデックスへのアクセスのみです。

インデックスの有効性を判断するには、「クエリ実行計画」と使用されるインデックスを表示する無料のオンライン サービスを使用して大まかに見積もることができます。