1

多対多の関係のための結合テーブルを作成しました。

テーブルには2つの列しかなくticketid、groupid

典型的なデータは

groupid    ticketid
20         56  
20         87
20         96
24         13
24         87
25         5

私の質問は、複合キーを作成するときに、ticketidその後に続く必要があるかどうかです。groupid

CONSTRAINT [PK_ticketgroup] PRIMARY KEY CLUSTERED 
    (
        [ticketid] ASC,
        [groupid] ASC
    )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
    ) ON [PRIMARY]

またはその逆、groupid続いてticketid

CONSTRAINT [PK_ticketgroup] PRIMARY KEY CLUSTERED 
        (
            [groupid] ASC,
                    [ticketid] ASC
        )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
        ) ON [PRIMARY]

オプション1ではticketid's、グループIDよりも一意である可能性が高く、複合キーの先頭にあるため、インデックスの検索が速くなりますか？それともこれはごくわずかですか？

4

2 に答える 2

2

違いはほとんど無視できるでしょう。

ただし、SQL Server では、最も選択的な列を最初に配置することをお勧めします。選択性の低い列が最初に配置されると、オプティマイザーはインデックスがあまり選択的ではないと判断し、それを無視することを選択する場合があります。詳細については、このsqlserverpedia.com Wiki 記事を参照してください。

于 2013-01-30T12:33:42.790 に答える
0

実際には 2 つのインデックスを作成します。チケット ID は一意である可能性が高いため、クラスター化インデックスは GroupID,TicketID の順序になります。次に、TicketID にクラスター化されていない非一意のインデックスを作成します。

その理由は、グループ ID のみに基づいてクエリを実行する場合、それらは論理的に連続しており、それらのブロックが存在するためです。他のインデックスは、TicketID のみが指定されている場合に最速になります。

データがどのようにクエリされるか (つまり、groupid と ticketid が常に提供される場合) によっては、全体的にはおそらく無視できると思います。

于 2013-01-30T12:52:52.523 に答える