2

私はいくつかの列を持つテーブルを持っています.2つの重要なものはappidとfileidです. 一緒に、テーブルの PK を構成します。テーブルの典型的な使用例は、appid x を含むファイルの数、または最も人気のある appid です。これらのクエリは、すべてのファイルではなく、ファイルのサブセットに対してのみ頻繁に実行されます。どちらの列も個別に一意ではありません。

それに基づいて、クラスター化されたインデックスの最良の選択は AppId になると思います。ただし、両方の列を PK として設定すると、追加の非クラスター化インデックスが作成され、appids の一意性の欠如 (多くの繰り返しがある) は、いずれにしても舞台裏で一意化列が必要になることを意味するため、 PK はクラスター化されており、別のクラスター化インデックスを指定していませんか? PK で最初に AppId を指定したと仮定すると、診断ファイル ID は舞台裏で一意識別子のように扱われ、最適なパフォーマンスが得られるでしょうか?

編集: 最初に言及するのを忘れていた重要なことは、APPId が着実に増加することはないということです。そのため、テーブルの中央に挿入が行われます。フィルファクタを使えばある程度は防げると思っていたのですが、テーブルがかなり大きくなってしまうので、それがどれだけ役立つかわかりません。

また、かなり頻繁に挿入されますが、一度に大きなチャンクが挿入されることはありません。おそらく、1 時間あたり数千行のようなものです。確実に増加し、その点でクラスター化インデックスの適切な選択となる値は実際にはありませんが、それがどれほど大きな取引であるかはわかりませんでした. クラスター化するのに適切な値を取得するためだけに id を追加することもできますが、選択が大幅に遅くなるように感じます。

4

2 に答える 2

3

If your two most popular queries are "how many files contain appId" and "which appId is most popular", you should make this indexed view:

CREATE VIEW
        v_appCount
WITH SCHEMABINDING
AS
        SELECT  appId, COUNT_BIG(*) AS cnt
        FROM    dbo.mytable
        GROUP BY
                appId
GO

CREATE UNIQUE CLUSTERED INDEX
        ux_v_appCount_appId
ON      v_appCount (appId)

This way you could run those queries:

SELECT  cnt
FROM    v_appCount
WHERE   appId = @myAppId

and

SELECT  TOP 100
        *
FROM    v_appCount va
ORDER BY
        appId DESC

almost instantly.

于 2013-04-17T22:25:01.177 に答える
1

複合 PK の問題は、それらがクラスター化されている場合に発生します。これは、テーブルの途中に挿入するとコンテンツの物理的な並べ替えが発生するためです。テーブルが巨大なサイズに達することが予想されない場合は、おそらく問題にはなりませんが、考慮すべきことは間違いありません。これが高選択テーブルで低挿入テーブルである場合、主キーの途中での挿入の影響も制限されることを付け加えておきます。クラスター化されていない主キーにすることは間違いありませんが、それにはパフォーマンスに関する考慮事項があります。

EDIT編集
を考慮して、自動インクリメントPK（非クラスター化）を実行し、一意の制約を作成することをお勧めします（これにより、一意の非クラスター化インデックスも作成されます）。基本的に、このテーブルにクラスター化インデックスを使用することはお勧めしません。それなしではパフォーマンスの違いはあまり見られないと思いますが、そこにあり、テーブルの途中で何千もの挿入を行った場合は違います。デッドロックはあなたを悩ませます。

この記事を簡単に読んでください。古いものですが、原則はまだ適用されます。

于 2013-04-17T21:36:05.577 に答える