2.1 执行全表选取或者低选择性选取
修改表结构，在MobileNo字段上建立聚集索引。然后再次执行刚才的SQL语句。得到的执行计划变为聚集索引扫描。IO统计消息为：
(1000 row(s) affected)
表'P_User'。扫描计数1，逻辑读取6 次，物理读取1 次，预读4 次，lob 逻辑读取0 次，lob 物理读取0 次，lob 预读0 次。
这里的逻辑读取变为6次。
内存情况如下：
内存中的变化是增加了一个非叶级的聚集索引页，而叶级的聚集索引则会和数据放在一起。
另外，可以查看该表索引的级别：
以下是引用片段：
SELECT database_id,object_id,index_id,index_level,page_count,record_count
FROM sys.dm_db_index_physical_stats
(DB_ID(N'TestGDB'), OBJECT_ID(N'dbo.P_User'), NULL, NULL , 'DETAILED');
从结果可以看到该表的聚集索引总共分2级。
因而逻辑读增加了2——(由于发生Clustered Index Scan，除了根级别的聚集索引页占用1次外，从根级别聚集索引定位到叶级别的聚集索引也将额外占用1次逻辑读)。
另外一个变化是只发生了一次物理读，即读取根级别的聚集索引页，另外4个数据页则通过预读方式而不是物理读从磁盘装入内存Buffer。这使得有聚集索引的情况下，执行SQL所直接花费的代价实际上更小。
2.2 执行高选择性选取
在建立聚集索引情况下，对性能有益的变化是：
对于Select Top 1 * From P_Order 或者Select * From P_Order Where MobileNo=28702这样的语句，在有聚集索引情况下，只会将最终记录所在的页读入内存。
测试3：建立非聚集索引情况下，执行SQL语句
3.1 执行全表选取或者低选择性选取
如果将表中同一字段的聚集索引换成非聚集索引，则可以看到如下特点：
执行全表扫描将和没有任何索引的情况相似，将读取所有的数据页到内存。此时,SQL Server的查询引擎实际上无法使用非聚集索引。
3.2 执行高选择性选取
将只读取最终数据所在的页到内存。通过查询计划可以看到，SQL Server在非聚集索引上使用INDEX SEEK，然后通过lookup 得到数据实际所在行(索引覆盖情况下例外，因为不需要定位到实际数据行)。
测试4：执行Nested Loop Join
在进行测试前,我们先准备另外一张表和数据。
以下是引用片段：
Create Table P_Order
( UserStatus int NOT NULL,
MobileNo int NOT NULL,
Sid int Not NULL,
LastSubTime DateTime
)
插入数据：
以下是引用片段：
Declare @i int
Set @i=20000
WHILE @i<30000
BEGIN
Insert Into P_Order
Select @i % 2,@i,@i-19999,GetUTCDate()
set @i=@i+1
END
可以看到，在执行全表扫描情况下，该表10000条数据总共占用38个内存数据页。
4.1 执行全表选取或者低选择性选取
以下是引用片段：
Select * From P_Order A
Inner Loop JOIN P_User B ON A.MobileNo=B.MobileNo
对于此种高选择性选择，默认情况下SQL Server不会执行Loop Join。因此，使用了强制性的联接提示。
在两个表都没有任何索引的情况下，可以看到：
两个表所有的数据页都将被加载到内存。逻辑读取代价高达6万多次——对于P_Order表中的每一条记录，都将在P_User表中进行遍历。
在其中一个表有聚集索引情况下，尽管逻辑读取相比刚才的6万多次已经大大下降，但仍然达到2万次。而且联接的次序对查询性能影响很大。因为其实际执行的是将SQL语句中前面的表作为联接的外部输入，而后面的表作为联接的内部输入。
在两个表都有聚集索引情况下，相比较而言，逻辑读仍然达到数千次(取决于最终输出的数据大小)，但相比较已经大大改善。而且表中的数据只有最终需要输出的部分才会被读入内存Buffer中。
