SQL server的复合密钥

我已经为多对多关系创建了一个联接表

表中只有2列，

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
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的

比groupid更可能是唯一的，并且它们将位于复合键的开头？还是可以忽略不计？

差异很可能可以忽略不计

---

但是，对于SQL Server，建议将最具选择性的列放在第一位。如果将选择性低的列放在第一位，优化器可能会确定您的索引选择性不高，并选择忽略它。有关更多信息，请参见此。

我实际上会创建两个索引。考虑到票证ID更可能是唯一的，聚集索引将是GroupID，按此顺序为TicketID。然后，我将在TicketID上创建一个非聚集非唯一索引

原因是，如果只希望基于组ID进行查询，则它们在逻辑上是连续的，并且会有一个块。当只指定TicketID时，另一个索引将提供最快的速度

我确实认为，根据查询数据的方式（即如果始终提供groupid和ticketid），总体而言，这可能可以忽略不计