0

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

Metadata 
ResultID (PK, int, not null) 
MappedFieldname (char(50), not null) 
Fieldname (PK, char(50), not null) 
Fieldvalue (text, null)

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

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

4

4 に答える 4

4

インデックス作成戦略は、テーブルのクエリ方法と、それぞれのクエリからどれだけのパフォーマンスを引き出す必要があるかに完全に依存します。

クラスタ化されたインデックスは、順序どおりでない挿入が行われた場合に (これを「ページ分割」と呼びます)、行を物理的に (ディスク上で) 強制的に再ソートできます。インデックス ページに空き領域がない大きなテーブルでは、これには時間がかかる場合があります。

2 つのフィールドにまたがるクラスター化インデックスが絶対に必要でない場合は、必要ありません。UNIQUE 制約のようなものであれば、必ず UNIQUE 制約にします。それらの再ソートは必要ありません。

テーブルに対する一般的なクエリを決定し、それに応じてインデックスを配置します。インデックスが多いほど、データの変更 (INSERT/UPDATE/DELETE) が遅くなります。フィルター処理や並べ替えが行われる可能性が低いフィールドなど、あまり多くのインデックスを作成しないでください。

通常、一緒にフィルター処理/並べ替えが行われるフィールドに対してのみ結合インデックスを作成します。

于 2009-02-15T19:52:05.410 に答える
1

クエリ、つまりデータのテーブルにヒットするクエリをよく見てください。インデックスは役立ちますか？その順序で (ResultID, FieldName) にインデックスがあり、特定の Fieldname の可能な ResultID 値を照会している場合、DBMS はインデックスを無視する可能性があります。対照的に、(FieldName, ResultID) にインデックスがある場合は、おそらく単純な値の検索 ( WHERE FieldName = 'abc') にインデックスを使用します。一意性に関しては、どちらのインデックスもうまく機能します。クエリの最適化に関しては、(少なくとも潜在的に) 大きな違いがあります。

EXPLAINを使用して、クエリが DBMS によってどのように処理されているかを確認します。

クラスター化されたインデックス作成と非クラスター化されたインデックス作成は、通常、DBMS における二次的な最適化効果です。インデックスが正しい場合、クラスター化されたインデックスと非クラスター化されたインデックスの間に小さな違いがあります (クラスター化されたインデックスの更新ペナルティは、わずかに短い選択時間の代償として大きくなります)。二次効果について心配する前に、他のすべてが最適化されていることを確認してください。

于 2009-02-15T22:02:24.753 に答える
0

私が見る限り、クラスタ化インデックスは問題ありません。他のインデックスに関しては、このテーブルを操作する典型的な SQL クエリを提供する必要があります。青からインデックスを作成するだけでは、決して良い考えではありません。断片化とインデックス作成について話しているのですが、クエリの実行が遅くなると思われるということですか? それとも、単にデータベース/インデックスを縮小/最適化したいですか?

時間外に時々インデックスを最適化するタスクを用意することをお勧めしますが、頻繁な/ランダムな挿入では、ページ分割 (これはパフォーマンスに影響します)。

于 2009-02-15T20:02:07.413 に答える
0

DB の保守戦略が切実に必要であることは承知しています。

その必要性を特定するための+1

私のバックグラウンドとしては、私はこの会社でアルバイトをしている大学生です。

勉強を続け、経験を積み、その間に経験豊富なコンサルタントを獲得してください。

テーブルには、それぞれ 4 つのスレッドを実行する 24 のワーカーが入力されます。

これは営業時間中は非常にミッション クリティカルであり、ダウンタイムは悪いニュースだと思いますか? もしそうなら、それで混乱しないでください。

ResultID と Fieldname にクラスター化インデックスがあります

あなたが示すように、ResultID は PK の最初の列ですか?

もしそうなら、私はそれが不十分に選択的であり、クエリのニーズが何であるかに応じて、PK フィールドの順序を交換する必要があると確信しています (この複合キーはクラスター化された PK には適していないように見えますが)。

結果は次のとおりです。

SELECT COUNT(*), COUNT(DISTINCT ResultID) FROM MyTable

たとえば、最初のカウントが 2 番目のカウントの 4 倍以上である場合、ResultsID の選択性が低いため、シークよりも優先してスキャンを取得する可能性が高く、いくつかの簡単な変更でパフォーマンスが大幅に向上します。

また、Fieldname は非常に広い (50 文字) ため、セカンダリ インデックスではすべてのインデックス エントリに 50 + 4 バイトが追加されます。フィールドは本当に VARCHAR ではなく CHAR ですか?

個人的には、リーフ ページの密度を上げることを検討します。90% では、ページに 1 つ程度の隙間しか残らないでしょう。ただし、5 億行の大規模なテーブルでは、パッキング密度が高くなると、ツリー内のレベルが少なくなり、検索のシークが少なくなる可能性があります。それに対して、特定のページのほぼすべての挿入には、ページ分割が必要になります。これはクラスター化された挿入を優先するため、適切ではない可能性があります (挿入データがおそらくクラスター化されていないことを考えると)。多くの場合と同様に、テストを行って、どのインデックス キー密度が最適かを確認する必要があります。SQL Server には、クエリがどのように解析されているか、クエリがキャッシュされているかどうか、テーブルのスキャンが何回発生しているか、どのクエリが "実行速度が遅い" かなどを分析するのに役立つツールがあります。

コンサルタントに見てもらい、アドバイスをもらいましょう。これは、ここで回答することで、実装する安全なソリューションが得られる質問ではありません。

5 億行を持ち、毎日の挿入負荷を削減するテーブルのメンテナンス ポリシーについては、本当に慎重に検討する必要があります。申し訳ありませんが、このような状態に陥る企業には非常に不満を感じています。

テーブルの最適化が必要です (クラスター化インデックスがないとオプションが少なくなるため、より適切な候補があると判断するまでそれを維持してください)。「オンライン」の最適化方法は、パフォーマンスにわずかな影響を与えますが、時間や CPU の制約を超えた場合は安全に中止できます [ただし、プログラミングが必要になる可能性が最も高い]。「静かな」スロットがある場合は、テーブルの最適化とインデックスの統計の更新に使用します。週末まで待ってすべてのテーブルを一度にやろうとしないでください - 毎日の静かな時間にできるだけ多く/多くのことをしてください (おそらく夜中)。

テーブルを最適化すると、トランザクション ログの使用量が大幅に増加する可能性があるため、TLog を頻繁にバックアップするようにしてください (10 分間の TLog バックアップ ポリシーがあり、テーブルの最適化中は 1 分ごとに増やして、最適化プロセスが実行されるようにします)。必要な Tlog スペースの定義にはなりません!)

于 2009-02-15T22:39:34.557 に答える