聚集索引
聚集索引指示表中数据的物理顺序，根据聚集排序索引键。该表只能定义一个聚集索引。假设您想要在具有数据的堆表上创建集群索引。作为第一步，如图2-5所示，SQL Server创建了数据的另一个副本，然后根据集群密钥的值对其进行排序。数据页链接在双链接列表中，其中每个页都包含指向链中的下一页和前一页的指针。这个列表称为索引的叶子级别，它包含实际的表数据。
注意，页面上的排序顺序由插槽数组控制。页面上的实际数据没有排序。
当叶子层包含多个页面时，SQL Server开始构建索引的中间层，如图2-6所示。
中间级存储每个叶级页的一行。它存储两段信息：物理地址和它引用的页面中的索引键的最小值。唯一的例外是第一页的第一行，其中SQL Server存储空值而不是最小索引键值。通过这种优化，当在表中插入具有最低键值的行时，SQL Server不需要更新非叶级行。中间层次的页面也链接到双链表。SQL Server添加了越来越多的中间级别，直到有一个仅包含单个页面的级别。这个级别称为根级别，并且它成为索引的入口点，如图2-7所示。
如您所见，索引总是具有一个叶子级别、一个根级别和零个或多个中间级别。唯一的例外是当索引数据适合单个页面时。在这种情况下，SQL Server不创建单独的根级页面，而索引仅由单个叶级页面组成。索引中的级别数量很大程度上取决于行和索引键的大小。例如，4字节整数列上的索引在中间级别和根级别上每行需要13个字节。这13个字节由一个2字节的时隙数组条目、一个4字节的索引键值、一个6字节的页指针和一个1字节的行开销组成，这足够了，因为索引键不包含可变长度和空列。
因此，您可以容纳每行8060字节/13字节=每页620行。这意味着，使用一个中间级别，可以存储最多620*620=384400个叶级页面的信息。如果数据行大小是200字节，那么可以在索引中存储每页40行，最多15376000行，只有三个级别。向索引中添加另一个中间级别将基本上覆盖所有可能的整数值。
注意，在实际生活中，索引碎片会减少这些数字。我们将在第6章中讨论索引碎片。
SQL Server可以以三种不同的方式从索引读取数据。第一个是通过有序扫描。假设我们要运行SELECT Name from dbo.Customers ORDER BY.CustomerId query。索引的叶级数据已经基于CustomerId列值进行了排序。因此，SQL Server可以扫描索引从第一页到最后一页的叶子级别，并按照存储行的顺序返回行。
SQL Server从索引的根页开始，然后从那里读取第一行。该行引用表中具有最小键值的中间页。SQL Server读取该页面，并重复该过程，直到在叶级找到第一个页面。然后，SQL Server开始逐行读取，遍历页面的链接列表，直到所有行都被读取。图2-8说明了这个过程。
前面查询的执行计划显示了集群索引扫描操作符，Ordered属性设置为true，如图2-9所示。
值得一提的是，触发有序扫描不需要order by子句。有序扫描仅仅意味着SQL Server根据索引键的顺序读取数据。
SQL Server可以在两个方向上（向前和向后）浏览索引。但是，您必须记住一个重要方面：SQL Server在反向索引扫描期间不使用并行性.
提示您可以通过检查执行计划中的索引扫描或索引查找操作符属性来检查扫描方向。但是，请记住，企业管理器并不在执行计划的图形表示中显示这些属性。您需要在执行计划中选择操作符并选择视图 /属性窗口菜单项或通过按F4键。企业版的SQL Server有一个称为旋转扫描的优化特性，允许多个任务共享相同的索引扫描。假设您有会话S1，它正在扫描索引。在扫描中间的某个时刻，另一个会话S2运行需要扫描相同索引的查询。通过旋转木马扫描，S2在其当前扫描位置连接S1。SQLServer只读取每个页面一次，将行传递给两个会话。
当S1扫描到达索引的结束时，S2从索引的开始开始扫描数据，直到S2扫描开始的点。旋转木马扫描是另一个示例，它说明了为什么您不能依赖于索引键的顺序，以及为什么在需要时应该始终指定ORDER BY子句。
排序扫描之后的下一个访问方法称为分配顺序扫描。SQL Server通过IAM页面访问表数据，类似于使用堆表的方式。来自dbo.Customers WITH(NOLOCK)查询的SELECT Name和图2-10说明了这种方法。图2-11显示了查询执行计划。
不幸的是，很难检测SQL Server何时使用分配顺序扫描。尽管执行计划中的Ordered属性显示为false，但它表明SQL Server并不关心行是否按索引键的顺序读取，而不关心使用分配顺序扫描。
分配顺序扫描可以更快地扫描大表，尽管它的启动成本较高。当表小时，SQLServer不使用此访问方法。另一个重要的考虑因素是数据一致性。SQL Server在具有集群索引的表中不使用转发指针，并且分配顺序扫描可能产生不一致的结果。由于分页导致的数据移动，可以多次跳过或读取行。因此，SQLServer通常避免使用分配顺序扫描。除非它以未提交读取或可串行化的事务隔离级别读取数据。
注意：我们将在第6章“索引分段”中讨论分页和分段，在第三部分“锁定、阻塞和并发”中讨论锁定和数据一致性。
最后一个索引访问方法称为索引查找。从dbo.CustomersWhhereCustomerId BETWEEN 4.7查询中的SELECT Name，图2-12说明了该操作
为了从表中读取行的范围，SQL Server需要从范围中找到具有最小键值的行，即SQL Server从根页面开始，其中第二行引用具有最小键值350的页面。它大于我们正在寻找的键值（4），并且SQL Server读取由根页面上的第一行引用的中间级数据页（1:170）。
类似地，中间页面将SQL Server引导到第一个叶级页面（1:176）。SQL Server读取该页，然后读取CustomerIds等于4和5的行，最后，从第二页读取剩余的两行。
执行计划如图2-13所示。
可以猜到，索引查找比索引扫描更有效，因为SQL Server只处理行和数据页的子集，而不扫描整个表。
从技术上讲，有两种索引查找操作。第一个称为单例查找，有时称为点查找，其中SQL Server查找并返回单行。您可以想到Cuffer-Id= 2谓词在哪里。另一种类型的索引查找操作称为范围扫描，它要求SQL Server查找键的最低值或最高值，并扫描（向前或向后）行集合，直到到达扫描范围的末尾。客户机介于4和7之间的谓词到范围扫描。两种情况都显示为执行计划中的索引查找操作。
正如您所猜到的，范围扫描完全可能迫使SQL Server处理索引中的大量数据页甚至所有数据页。例如，如果将查询更改为使用WHERE CustomerId>0谓词，SQL Server将读取所有行/页，尽管在执行计划中将显示Index Seek操作符。您必须牢记这种行为，并在查询性能优化期间始终分析范围扫描的效率。
在关系数据库中有一个称为SARGable谓词的概念，它代表可搜索参数。如果SQL Server可以利用索引查找操作（如果存在索引），则谓词是SARGable。简言之，当SQL Server可以隔离要处理的索引键值的单个值或范围时，谓词就是SARGable，从而限制了谓词评估期间的搜索。显然，写作是有益的。使用sgabess谓词进行查询，并尽可能使用索引查找。
SARGable谓词包括下列操作符：=、>、>=、<、<=、IN、BETWEEN和LIKE（在前缀匹配的情况下）。非SARGable操作符包括NOT、<>、LIKE（在非前缀匹配的情况下）和NOT IN。
使谓词不可SARGable的另一种情况是对表列使用函数或数学计算。SQL Server必须调用该函数或对其处理的每行执行计算。幸运的是，在某些情况下，您可以重构查询以使得这样的谓词SARGable。表2-1显示了一些例子。
您必须牢记的另一个重要因素是类型转换。 在某些情况下，您可以使用不正确的数据类型使谓词非SARGable。 让我们创建一个带有varchar列的表，并用一些数据填充它，如清单2-6所示。
聚簇索引键列定义为varchar，即使它存储整数值。 现在，让我们运行两个选择，如清单2-7所示，并查看执行计划
如图2-14所示，对于整数参数，SQL Server扫描聚簇索引，将varchar转换为每行的整数。 在第二种情况下，SQL Server在开始时将整数参数转换为varchar，并使用更高效的聚簇索引查找操作。
提示请注意连接谓词中的列数据类型。 隐式或显式数据类型转换可能会显着降低查询的性能。
在unicode字符串参数的情况下，您将观察到非常类似的行为。 让我们运行清单2-8中所示的查询。 图2-15显示了语句的执行计划
清单2-8 SARG谓词和数据类型：使用字符串参数选择。
图2-15。 SARG谓词和数据类型：带字符串参数的执行计划
如您所见，对于varchar列，unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为unicode。 因此，除非参数数据，否则SQL Server客户端库会为字符串对象生成unicode（nvarchar）参数type显式指定为varchar。 这使得谓词不具有SARG，并且由于不必要的扫描，它可能导致主要的性能命中，即使对varchar列进行索引也是如此。
)。Value=stringVariable而不是Parameters.Add("@ParamName")。Value=stringVariable重载。在ORM框架中使用映射来显式地指定类中的非Unicode属性。" >重要的是始终在客户端应用程序中指定参数数据类型。例如，在ADO.Net中，使用Parameters.Add("@ParamName)、SqlDbType.Varchar、<Size>)。Value=stringVariable而不是Parameters.Add("@ParamName")。Value=stringVariable重载。在ORM框架中使用映射来显式地指定类中的非Unicode属性。
还值得一提的是，VARCHAR参数对于NVARCHAR Unicode数据列是可处理的
综合指数
具有多个键列的索引称为复合（或复合）索引。复合索引中的数据按每列从最左到最右的列进行排序。图2-16显示了复合索引的结构。