我们在学 sqlserver 的时候，大多教科书和前辈们都说状态少的字段不要建索引，由此带来的开销还不如不建索引，但是这句话有多少人真的知道，或者说有多少人真的对此有比较深刻的理解，而不是听别人道听途说。。。这样记得快，忘记的也不慢。。。这篇我来分析一下这句话到底有几个意思。

一：现象

首先我们还是用测试数据来发现问题，我先建立一个 Person，有 5 个字段，建表 sql 如下：

DROP TABLE dbo.Person

CREATE TABLE Person(ID INT PRIMARY KEY IDENTITY,NAME VARCHAR(900),Age INT,Email VARCHAR(20),isMan INT )

-- 在 isMan 字段创建非聚集索引（0：女 1：男）
CREATE INDEX idx_isMan ON dbo.Person(isMan)

DECLARE @ch AS INT=0

WHILE @ch<=100000
BEGIN
INSERT INTO dbo.Person(NAME,Age,Email,isMan)
VALUES
(
REPLICATE(CHAR(@ch),50),
@ch,
CAST(CAST(RAND()*1000000000 AS INT) AS VARCHAR(10))+'qq.com',
@ch%2
)
SET @ch=@ch+1
END

通过上面的 sql 发现 ID 为聚集索引，isMan 为非聚集索引，isMan 也就是两种状态（0,1），并且插入 10w 条记录，截图如下：

sql 都做完了，接下来要做的事情就是查询下：isMan=1 的记录，如下图：

我靠。。。我明明是在 isMan 上做数据检索的，怎么就变成 “聚集索引扫描”了？？？这 sqlserver 什么意思嘛，居然不走我的“idx_isMan”索引，却走他的“聚集索引(PKPerson3214EC276EF57B66)”。。。。同时也看到上面的”逻辑读取”为 521。。。说明在内存中走了 521 个数据页。但是我不服呀。。。我一定要让执行计划走我的索引。。。办法就是强制指定。。。如下图。

看到上面的图，你是不是已经疯了。。。我才捞 5w 的数据，你给我走了 10w 多次数据页。。。这么说 1 条记录要走两个数据页。。。而扫描聚集索引才走 521 个数据页，相差 200 倍。。。难怪执行计划打死也不走“idx_isMan”这条索引。。。

二：分析原因

现在很生气，整个人都不好了，为什么会这样？？？为了找出问题，我们还得看数据页。

DBCC TRACEON(3604,2588)
DBCC IND(Ctrip,Person,-1)

通过上面的三个图，大概可以看到，10w 条数据用了 697 数据页，其中聚集索引有 521 个，非聚集索引为 176 个，这也说明了上面的”聚集索引扫描“走遍了它自己所有的数据页来才捞出数据，同时还发现这两个索引都有一个共同特征就是，只有一个根节点(indexLevel=1）和无数个（indexLevel=0）叶子节点，然后我脑子里面就有一幅图出来了。。。

上面就是我构思出来的图，这个专业一点的名字叫做书签查找。。。我们通过建立”idx_isMan“索引后，就会构建右半图的 B 树结构，其中索引记录会存放两个值，一个是索引值 isMan 和一个聚集索引值 ID，如果你不相信的话，可以通过 DBCC Page 去探索”idx_isMan”的索引页，你也可以通过 DBCC SHOW_STATISTICS 去查看，如图：

然后引擎通过“idx_isMan“扫描后，拿到了 key 值，但是非常可惜，我是 select * 的，所以必须还要喷出记录中的 Name，Emai 等 l 字段，但是”index_isMan”中并没有保存这几个字段，所以必须通过 key 去”聚集索引“的 B 树中去找。。。最后通过”聚集索引“的 B 树找到了目标记录，这也就是所谓的执行计划中的”键查找“，然后喷出”Name，Email“等字段。。。。问题就在这里。。。因为我这样来回的蹦跶蹦跶。。。造成了找出完整的一个记录，需要蹦跶 2-3 次数据页。。。具体的寻找记录，可参考图中的”紫色线条“，最后也就造成了 10w 多次蹦跶。。。

三：启示

那这个例子给我们什么启示呢？？？仔细想想你就知道。。。使用非聚集索引，千万不要捞取过多的数据。。。因为过多的数据会造成在多个 B 树中来回的蹦跶。。。想要做到捞取数据较少，就必须在高唯一性的字段上建立索引，这样的话在非聚集索引 B 树中符合的数据相对较少，也就减少了我蹦跶到”主键索引“的 B 树次数。。。这样的话来回蹦跶的次数远远比”聚集索引“扫描来的实惠，对不对。。。

四：结论

必须在唯一性较高的字段上建立非聚集索引。