1

私はまだSQLに精通していません。私は学んでいますが、それは遅いプロセスです。私は、SQL Server のデータベースに大量の情報を格納するプロジェクトに取り組んでいます。テーブルの 1 つである ContactInformation では、すべてのアドレス情報で構成される非クラスター化インデックスが 900 バイトを超えるため、エントリを変更しようとするとエラーが発生します。sys.dm_db_index_usage_statsテーブル内のエントリを変更すると 3user_seeksと 1になることを確認してきましたuser_update。

C# コードはインデックスを直接呼び出していないようです。19 個のパラメーターを持つさまざまなDbCommandストアド プロシージャ コマンドで構成される単一のコマンドを実行します。私の考えでは、インデックスを削除するか、操作するインデックスを小さくすることを期待して、パラメーターの数を減らして複数の更新に分割Updateしようとします。DbCommand

私は経験が不足しているため、少し海にいます。次の方向へのアドバイスを歓迎します。

インデックスは次のもので構成されています。

| Name                 | Data Type     | Size |
|----------------------|---------------|------|
| ContactInformationID | int           | 4    |
| CompanyID            | smallint      | 2    |
| Address1             | nvarchar(420) | 840  |
| Address2             | nvarchar(420) | 840  |
| City                 | nvarchar(420) | 840  |
| State                | nvarchar(220) | 440  |
| PostalCode           | nvarchar(120) | 240  |
| Country              | nvarchar(220) | 440  |

はい、ほとんどの列が特大です。このデータベースは別のプロジェクトから継承したようです。当社のソフトウェアでは、一部の外れ値はありますが、ほとんどの列が 100 文字以内に制限されています。

4

2 に答える 2

1

インデックス サイズの制限は、キー列にのみ適用されます。これは、すべての B ツリー ベース ストレージ モード (NCI および CI) に適用されます。この制限は、ツリーの高さを制限するためにツリーのファンアウトをある程度確保するために存在します。

Address1 や Address2 などの列をシークする必要がない場合 (それらも null である可能性があることを考慮して)、それらの列に含まれる列を作成します。

インデックス キーは、一意のインデックスになる最短のキー プレフィックスよりも長くしないでください。その後のすべての列は、その列が含まれていることに比べて決して役に立ちません。

于 2014-08-13T22:38:05.063 に答える
0

ContactInformationID が一意である場合は、そうなる可能性が非常に高いと思いますが、インデックスに他のフィールドを含めることは無意味です。

このようなインデックスは、ContactInformationID の値がクエリ パラメータとして存在するクエリでのみ役立ちます。存在する場合、残りのフィールドは重要ではありません。

于 2014-08-13T20:21:42.907 に答える