1

假设我有一张这样的桌子。Id 是主键，所以我知道我得到了一个索引。

CREATE TABLE Employer
(
    Id VARCHAR(64) NOT NULL,
    EntityId VARCHAR(64) NOT NULL,
    Name VARCHAR(64) NOT NULL,
    Address1 VARCHAR(64) NOT NULL,
    Address2 VARCHAR(64) NOT NULL,
    City VARCHAR(64) NOT NULL,
    JobTitle VARCHAR(64) NOT NULL,
    StateCode VARCHAR(64) NOT NULL,
    ZipCode VARCHAR(64) NOT NULL,
    CONSTRAINT PK_Employer_Id PRIMARY KEY CLUSTERED (Id ASC)
    WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

假设我添加了另一个索引来帮助进行一些特殊的搜索（尽管原因并不相关）。是否有理由将 Id（主键）作为索引中的列之一包含在内？我有 SQL 专家告诉我这是浪费空间，因为索引已经以某种方式包含主键。

CREATE INDEX [idxEmployerByNameAddress1City] on [Employer] ([EntityId], [Id], [Name], [Address1], [City])
4

2 回答 2

0

如果您的二级索引不以主键列开头，则主键与二级索引无关。

另一方面，如果您的索引基于前两列是唯一的，就像这里的情况一样，那么在键中添加更多列是没有意义的——这只会浪费索引中的空间。

于 2013-06-21T17:07:18.723 回答
0

索引用于多种目的。其中之一是满足仅使用索引中的列的查询。因此，如果您有如下查询：

select col, max(pk)
from t
group by col

并且您有一个索引，那么查询必须从数据页t(col)中获取 的值。pk如果主键在索引中，则不需要原始数据页。

因此，在某些情况下，在索引中包含主键是个好主意。

顺便说一句，我完全同意主键不应该是 varchar(64) 的评论。我鼓励您使用整数主键，使用identity(). 而且，出于某种原因，我认为拥有可变长度的主键是一个坏主意——可能是因为混淆了，比如说，'A'和' A'——它们是不同的，但在打印出来时可能看起来并没有什么不同。

我要进一步指出，如果主键存储在其他表中，那么索引中浪费空间的问题就没有实际意义。您浪费了如此多的空间来存储如此大的主键，以至于在索引中浪费更多的空间并不是主要问题。

于 2013-06-21T17:19:46.573 回答