图
大量转发指针导致额外的I/O操作，并显著降低了访问数据的查询的性能。本书的配套材料包括在大范围内用包含大量数据的表演示这个问题的脚本。
当转发行的大小被另一次更新减少，并且带有转发指针的数据页有足够的空间容纳更新后的行版本时，SQL Server可能会将其移动回原来的数据页并删除转发指针行。然而，摆脱所有转发指针的唯一可靠方法是重新构建堆表。您可以通过使用ALTER TABLE REBUILD语句来实现这一点。
堆表在登台环境中非常有用，在登台环境中，您希望尽可能快地将大量数据导入系统。将数据插入堆表通常比将数据插入具有聚集索引的表更快。然而，在常规工作负载期间，具有聚集索引的表通常优于堆表，堆表具有次优空间控制和通过转发指针引入的额外I/O操作。
聚集索引
一个聚集索引指示表中数据的物理顺序，表按照聚集索引键进行排序。表只能定义一个聚集索引。
让我们假设您希望在堆表上使用数据创建一个聚集索引。作为第一步，如图2-5所示，SQL Server创建数据的另一个副本，然后根据聚集键的值对数据进行排序。数据页链接在一个双链列表中，其中每个页面都包含指向链中的下一个和前一个页面的指针。这个列表称为索引的叶级，它包含实际的表数据。
图 2 - 5。聚类索引结构:叶级
注意：页面上的排序顺序由插槽阵列控制。页面上的实际数据未排序。
当叶子级别由多个页面组成时，SQL Server开始构建索引的中间级别，如图2-6所示。
图2-6。聚集索引的结构：中间级别和叶子级别
中间级别为每个叶级页面存储一行。它存储两条信息：物理地址和引用的页面中的索引键的最小值。唯一的例外是第一页上的第一行，其中SQL Server存储NULL而不是最小索引键值。有了这样的优化，SQL插入时，服务器不需要更新非叶子级别行表中键值最小的行。页面的中间级别也链接到双链表。 SQL服务器添加越来越多的中间级别，直到有一个仅包括单页级别。此级别称为根级别，它成为索引的入口点，如图所示图2-7。
图2-7. 聚集索引结构：根级别
如您所见，索引始终有一个叶子级别，一个根级别，和零个或多个中间级别。唯一的不同是什么时候索引数据适合单个页面。在这种情况下，SQL Server不会创建单独的根级别页面，索引由单叶子级别页面组成。索引中的级别数量主要取决于行和索引键大小。例如，索引就可以了4字节整数列每行需要13个字节中级和根级。这13个字节由一个2字节的插槽组成 数组条目，4字节索引键值，6字节页面指针和1-字节行开销，这是足够的，因为索引键没有包含可变长度和NULL列。结果，你可以容纳8,060字节/每行13字节=每页620行。这意味着，通过一个中间级别，您可以存储信息大约620 * 620 = 384,400个叶子级页面。如果数据行大小为200字节，每个叶级页面最多可存储40行索引中有15,376,000行，只有三个级别。添加另一个指数的中间级别基本上涵盖所有可能的整数值。
注意：在现实生活中，索引碎片会减少这些碎片数字。我们将在第6章讨论索引碎片。
SQL Server可以通过三种不同的方式从中读取数据指数。第一个是有序扫描。让我们假设我们想要运行SELECT Name FROM dbo.Customers ORDER BY CustomerId查询。索引的叶级别上的数据已经基于排序在CustomerId列值上。因此，SQL Server可以扫描索引的叶级从第一页到最后一页并返回行按存储顺序排列。
SQL Server从索引的根页开始并从中读取第一行。该行引用了中间页面表中的最小键值。 SQL Server读取该页面和重复该过程，直到找到叶子级别的第一页。然后，SQL Server开始逐个读取行，通过链接列表的页面，直到读取所有行。图2-8说明了这个过程。
图2-8。有序索引扫描
上一个查询显示了聚集索引将Ordered属性设置为true的运算，如下图2-9所示。
图2-9。有序索引扫描执行计划
值得一提的是，排序不是必需的要触发的有序扫描。有序扫描只意味着SQL服务器根据索引键的顺序读取数据。SQL Server可以向前和向后扫描两个方向的索引。但是，必须牢记一个重要方面：SQL在反向索引扫描期间，服务器不使用并行性。
注意：您可以通过检查索引扫描来检查扫描方向或执行计划中的索引运算符属性。但是，请注意，Management Studio不会显示这些内容执行计划的图形表示中的属性。您需要打开“属性”窗口以通过选择运算符来查看它在执行计划中并选择“视图/属性窗口”菜单项目或按F4键。
SQL Server企业版具有优化的功能称为旋转木马扫描，允许多个任务共享相同的索引扫描。让我们假设您有会话S1，即扫描索引。在扫描中间的某个点，另一个会话S2运行需要扫描相同索引的查询。有了旋转木马扫描，S2在其当前扫描位置加入S1。 SQL服务器只读取每个页面一次，将行传递给两个会话。
当S1扫描到达索引的结束时，S2从索引的开始开始扫描数据，直到S2扫描开始的点。旋转木马扫描是另一个示例，它说明了为什么您不能依赖于索引键的顺序，以及为什么在需要时应该始终指定ORDER BY子句。排序扫描之后的下一个访问方法称为分配顺序扫描。S QL Server通过IAM页面访问表数据，类似于使用堆表的方式。SELECT Name from dbo.Customers WITH(NOLOCK)查询和图2-10说明了这种方法。图2-11显示了查询执行计划。
图2-10。分配顺序扫描
图2-11。分配顺序扫描执行计划
不幸的是，SQL Server使用时很难检测分配顺序扫描。即使在Ordered属性的执行计划显示false，表示SQL Server不关心是否按索引键的顺序读取行，而不是使用了分配订顺序扫描。
扫描大表时，分配顺序扫描可以更快，虽然它具有更高的启动成本。 当表很小时SQL Server不使用它当访问方法。另一个重要的考虑是数据一致性。SQL Server不使用转发指针，具有聚集索引的表和分配顺序扫描可以产生不一致的结果。由于分页导致的数据移动，可以多次跳过或读取行。因此，SQLServer通常避免使用分配顺序扫描。除非它以READ UNCOMMITTED或SERIALIZABLE事务隔离级别读取数据。
注意：我们将在第6章“索引分段”中讨论分页和分段，在第三部分“锁定、阻塞和并发”中讨论锁定和数据一致性。
最后一个索引访问方法称为索引查找。 SELECT名称FROM dbo.Customers WHERE CustomerId BETWEEN 4 AND 7查询.图2-12说明了该操作
图2-12。索引查找
为了从表中读取行的范围，SQL Server需要从范围中找到具有最小键值的行是4. SQL Server以根页面开始，其中第二行引用最小键值为350的页面。它大于我们要查找的键值（4），并且SQL Server读取根页面上第一行引用的中间级数据页（1：170）。
同样，中间页面将SQL Server引向第一个叶子 - 级别页面（1：176）。 SQL Server读取该页面，然后读取行CustomerIds等于4和5，最后，它读取两个第二页的剩余行。
执行计划如图2-13所示。
图2-13。索引查找执行计划
您可以猜测，索引搜索比索引扫描更有效，因为SQL Server只处理行和数据页的子集，而不是扫描整个表。
从技术上讲，索引搜索操作有两种。第一种称为单例查找，有时称为点查找，其中SQL Server寻找并返回单行。您可以考虑将WHERE CustomerId = 2谓词作为示例。另一种类型的索引查找操作称为范围扫描，它要求SQL Server查找键的最低值或最高值，并扫描（向前或向后）行集，直到达到扫描范围的末尾。 CustomerId BETWEEN 4和7之间的谓词WHERE导致范围扫描。这两种情况都在执行计划中显示为INDEX SEEK操作。
可以猜到，范围扫描完全可以强制SQL Server处理索引中的大量甚至所有数据页。例如，如果您将查询更改为使用WHERE CustomerId> 0谓词，则SQL Server将读取所有行/页，即使您在执行计划中显示了Index Seek运算符。您必须牢记此行为，并始终在查询性能调整期间分析范围扫描的效率。
关系数据库中有一个名为SARGable谓词的概念，它代表Search Argumentable。如果索引存在，如果SQL Server可以使用索引查找操作，则谓词是SARGable。简而言之，当SQL Server可以隔离要处理的索引键值的单个值或范围时，谓词是SARGable，因此在谓词评估期间限制搜索。显然，使用SARGable谓词编写查询并尽可能利用索引查找是有益的。 SARGable谓词包括以下运算符：=，>，> =，<，<=，IN，BETWEEN和LIKE（在前缀匹配的情况下）。非SARGable运算符包括NOT，<>，LIKE（在非前缀匹配的情况下）和NOT IN。使谓词非SARGable的另一种情况是对表列使用函数或数学计算。 SQL Server必须为其处理的每一行调用该函数或执行计算。幸运的是，在某些情况下，您可以重构查询以使这样的谓词成为SARGable。
表2-1列出了一些例子。
表2-1。 将非SARGable谓词重构为SARGable的示例
另一个重要因素是类型转换。 在某些情况下，您可以使用不正确的数据类型使谓词非SARGable。让我们创建一个带有varchar列的表，并用一些数据填充它，如清单2-6所示。
清单2-6 SARG谓词和数据类型：测试表创建
create table dbo.Data
(
VarcharKey varchar(10) not null,
Placeholder char(200)
);
create unique clustered index IDX_Data_VarcharKey
on dbo.Data(VarcharKey);
;with N1(C) as (select 0 union all select 0) -- 2 rows
,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows
,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows
,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows
,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows
,IDs(ID) as (select row_number() over (order by (select null)) from N5)
insert into dbo.Data(VarcharKey)
select convert(varchar(10),ID) from IDs;
聚集索引键列定义为varchar，用它存储整数值。现在，让我们运行两个选择，如清单2-7所示，并查看执行计划。
Listing 2-7. SARG predicates and data types: Select with integer parameter
清单2-7 SARG谓词和数据类型：选择使用整数参数
declare
@IntParam int = '200'
select * from dbo.Data where VarcharKey = @IntParam;
select * from dbo.Data where VarcharKey = convert(varchar(10),@IntParam);
如图2-14所示，对于整数参数，SQL Server扫描聚簇索引，将varchar转换为每行的整数。 在第二种情况下，SQL Server在开始时将整数参数转换为varchar，并使用更高效的聚簇索引查找操作。
图2-14。 SARG谓词和数据类型：带整数参数的执行计划
注意：请注意连接谓词中的列数据类型。 隐式或显式数据类型转换可能会显着降低查询的性能。
在unicode字符串参数的情况下，您将观察到非常类似的行为。 让我们运行清单2-8中所示的查询。 图2-15显示了语句的执行计划。
Listing 2-8. SARG predicates and data types: Select with string parameter
清单2-8 SARG谓词和数据类型：使用字符串参数选择
select * from dbo.Data where VarcharKey = '200';
select * from dbo.Data where VarcharKey = N'200'; -- unicode parameter
如您所见，对于varchar列，unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为unicode。 因此，除非将参数数据类型显式指定为varchar，否则SQL Server客户端库会为字符串对象生成unicode（nvarchar）参数。 这使得谓词不具有SARG，并且由于不必要的扫描，它可能导致主要的性能命中，即使对varchar列进行索引也是如此。
注意：始终在客户端应用程序中指定参数数据类 例如，在ADO.Net中使用
在unicode字符串参数的情况下，您将观察到非常类似的行为。运行清单2-8中所示的查询。 图2-15显示了语句的执行计划。
清单2-8 SARG谓词和数据类型：使用字符串参数选择
select * from dbo.Data where VarcharKey = '200';
select * f
表和索引:内部结构和访问方法
图 2 – 4。转发指针和I/O:存在转发指针时读取数据
大量转发指针导致额外的I/O操作，并显著降低了访问数据的查询的性能。本书的配套材料包括在大范围内用包含大量数据的表演示这个问题的脚本。
当转发行的大小被另一次更新减少，并且带有转发指针的数据页有足够的空间容纳更新后的行版本时，SQL Server可能会将其移动回原来的数据页并删除转发指针行。然而，摆脱所有转发指针的唯一可靠方法是重新构建堆表。您可以通过使用ALTER TABLE REBUILD语句来实现这一点。
堆表在登台环境中非常有用，在登台环境中，您希望尽可能快地将大量数据导入系统。将数据插入堆表通常比将数据插入具有聚集索引的表更快。然而，在常规工作负载期间，具有聚集索引的表通常优于堆表，堆表具有次优空间控制和通过转发指针引入的额外I/O操作。
聚集索引
一个聚集索引指示表中数据的物理顺序，表按照聚集索引键进行排序。表只能定义一个聚集索引。
让我们假设您希望在堆表上使用数据创建一个聚集索引。作为第一步，如图2-5所示，SQL Server创建数据的另一个副本，然后根据聚集键的值对数据进行排序。数据页链接在一个双链列表中，其中每个页面都包含指向链中的下一个和前一个页面的指针。这个列表称为索引的叶级，它包含实际的表数据。
图 2 - 5。聚类索引结构:叶级
注意：页面上的排序顺序由插槽阵列控制。页面上的实际数据未排序。
当叶子级别由多个页面组成时，SQL Server开始构建索引的中间级别，如图2-6所示。
图2-6。聚集索引的结构：中间级别和叶子级别
中间级别为每个叶级页面存储一行。它存储两条信息：物理地址和引用的页面中的索引键的最小值。唯一的例外是第一页上的第一行，其中SQL Server存储NULL而不是最小索引键值。有了这样的优化，SQL插入时，服务器不需要更新非叶子级别行表中键值最小的行。页面的中间级别也链接到双链表。 SQL服务器添加越来越多的中间级别，直到有一个仅包括单页级别。此级别称为根级别，它成为索引的入口点，如图所示图2-7。
图2-7. 聚集索引结构：根级别
如您所见，索引始终有一个叶子级别，一个根级别，和零个或多个中间级别。唯一的不同是什么时候索引数据适合单个页面。在这种情况下，SQL Server不会创建单独的根级别页面，索引由单叶子级别页面组成。索引中的级别数量主要取决于行和索引键大小。例如，索引就可以了4字节整数列每行需要13个字节中级和根级。这13个字节由一个2字节的插槽组成 数组条目，4字节索引键值，6字节页面指针和1-字节行开销，这是足够的，因为索引键没有包含可变长度和NULL列。结果，你可以容纳8,060字节/每行13字节=每页620行。这意味着，通过一个中间级别，您可以存储信息大约620 * 620 = 384,400个叶子级页面。如果数据行大小为200字节，每个叶级页面最多可存储40行索引中有15,376,000行，只有三个级别。添加另一个指数的中间级别基本上涵盖所有可能的整数值。
注意：在现实生活中，索引碎片会减少这些碎片数字。我们将在第6章讨论索引碎片。
SQL Server可以通过三种不同的方式从中读取数据指数。第一个是有序扫描。让我们假设我们想要运行SELECT Name FROM dbo.Customers ORDER BY CustomerId查询。索引的叶级别上的数据已经基于排序在CustomerId列值上。因此，SQL Server可以扫描索引的叶级从第一页到最后一页并返回行按存储顺序排列。
SQL Server从索引的根页开始并从中读取第一行。该行引用了中间页面表中的最小键值。 SQL Server读取该页面和重复该过程，直到找到叶子级别的第一页。然后，SQL Server开始逐个读取行，通过链接列表的页面，直到读取所有行。图2-8说明了这个过程。
图2-8。有序索引扫描
上一个查询显示了聚集索引将Ordered属性设置为true的运算，如下图2-9所示。
图2-9。有序索引扫描执行计划
值得一提的是，排序不是必需的要触发的有序扫描。有序扫描只意味着SQL服务器根据索引键的顺序读取数据。SQL Server可以向前和向后扫描两个方向的索引。但是，必须牢记一个重要方面：SQL在反向索引扫描期间，服务器不使用并行性。
注意：您可以通过检查索引扫描来检查扫描方向或执行计划中的索引运算符属性。但是，请注意，Management Studio不会显示这些内容执行计划的图形表示中的属性。您需要打开“属性”窗口以通过选择运算符来查看它在执行计划中并选择“视图/属性窗口”菜单项目或按F4键。
SQL Server企业版具有优化的功能称为旋转木马扫描，允许多个任务共享相同的索引扫描。让我们假设您有会话S1，即扫描索引。在扫描中间的某个点，另一个会话S2运行需要扫描相同索引的查询。有了旋转木马扫描，S2在其当前扫描位置加入S1。 SQL服务器只读取每个页面一次，将行传递给两个会话。
当S1扫描到达索引的结束时，S2从索引的开始开始扫描数据，直到S2扫描开始的点。旋转木马扫描是另一个示例，它说明了为什么您不能依赖于索引键的顺序，以及为什么在需要时应该始终指定ORDER BY子句。排序扫描之后的下一个访问方法称为分配顺序扫描。S QL Server通过IAM页面访问表数据，类似于使用堆表的方式。SELECT Name from dbo.Customers WITH(NOLOCK)查询和图2-10说明了这种方法。图2-11显示了查询执行计划。
图2-10。分配顺序扫描
图2-11。分配顺序扫描执行计划
不幸的是，SQL Server使用时很难检测分配顺序扫描。即使在Ordered属性的执行计划显示false，表示SQL Server不关心是否按索引键的顺序读取行，而不是使用了分配订顺序扫描。
扫描大表时，分配顺序扫描可以更快，虽然它具有更高的启动成本。 当表很小时SQL Server不使用它当访问方法。另一个重要的考虑是数据一致性。SQL Server不使用转发指针，具有聚集索引的表和分配顺序扫描可以产生不一致的结果。由于分页导致的数据移动，可以多次跳过或读取行。因此，SQLServer通常避免使用分配顺序扫描。除非它以READ UNCOMMITTED或SERIALIZABLE事务隔离级别读取数据。
注意：我们将在第6章“索引分段”中讨论分页和分段，在第三部分“锁定、阻塞和并发”中讨论锁定和数据一致性。
最后一个索引访问方法称为索引查找。 SELECT名称FROM dbo.Customers WHERE CustomerId BETWEEN 4 AND 7查询.图2-12说明了该操作
图2-12。索引查找
为了从表中读取行的范围，SQL Server需要从范围中找到具有最小键值的行是4. SQL Server以根页面开始，其中第二行引用最小键值为350的页面。它大于我们要查找的键值（4），并且SQL Server读取根页面上第一行引用的中间级数据页（1：170）。
同样，中间页面将SQL Server引向第一个叶子 - 级别页面（1：176）。 SQL Server读取该页面，然后读取行CustomerIds等于4和5，最后，它读取两个第二页的剩余行。
执行计划如图2-13所示。
图2-13。索引查找执行计划
您可以猜测，索引搜索比索引扫描更有效，因为SQL Server只处理行和数据页的子集，而不是扫描整个表。
从技术上讲，索引搜索操作有两种。第一种称为单例查找，有时称为点查找，其中SQL Server寻找并返回单行。您可以考虑将WHERE CustomerId = 2谓词作为示例。另一种类型的索引查找操作称为范围扫描，它要求SQL Server查找键的最低值或最高值，并扫描（向前或向后）行集，直到达到扫描范围的末尾。 CustomerId BETWEEN 4和7之间的谓词WHERE导致范围扫描。这两种情况都在执行计划中显示为INDEX SEEK操作。
可以猜到，范围扫描完全可以强制SQL Server处理索引中的大量甚至所有数据页。例如，如果您将查询更改为使用WHERE CustomerId> 0谓词，则SQL Server将读取所有行/页，即使您在执行计划中显示了Index Seek运算符。您必须牢记此行为，并始终在查询性能调整期间分析范围扫描的效率。
关系数据库中有一个名为SARGable谓词的概念，它代表Search Argumentable。如果索引存在，如果SQL Server可以使用索引查找操作，则谓词是SARGable。简而言之，当SQL Server可以隔离要处理的索引键值的单个值或范围时，谓词是SARGable，因此在谓词评估期间限制搜索。显然，使用SARGable谓词编写查询并尽可能利用索引查找是有益的。 SARGable谓词包括以下运算符：=，>，> =，<，<=，IN，BETWEEN和LIKE（在前缀匹配的情况下）。非SARGable运算符包括NOT，<>，LIKE（在非前缀匹配的情况下）和NOT IN。使谓词非SARGable的另一种情况是对表列使用函数或数学计算。 SQL Server必须为其处理的每一行调用该函数或执行计算。幸运的是，在某些情况下，您可以重构查询以使这样的谓词成为SARGable。
表2-1列出了一些例子。
表2-1。 将非SARGable谓词重构为SARGable的示例
另一个重要因素是类型转换。 在某些情况下，您可以使用不正确的数据类型使谓词非SARGable。让我们创建一个带有varchar列的表，并用一些数据填充它，如清单2-6所示。
清单2-6 SARG谓词和数据类型：测试表创建
create table dbo.Data
(
VarcharKey varchar(10) not null,
Placeholder char(200)
);
create unique clustered index IDX_Data_VarcharKey
on dbo.Data(VarcharKey);
;with N1(C) as (select 0 union all select 0) -- 2 rows
,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows
,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows
,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows
,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows
,IDs(ID) as (select row_number() over (order by (select null)) from N5)
insert into dbo.Data(VarcharKey)
select convert(varchar(10),ID) from IDs;
聚集索引键列定义为varchar，用它存储整数值。现在，让我们运行两个选择，如清单2-7所示，并查看执行计划。
Listing 2-7. SARG predicates and data types: Select with integer parameter
清单2-7 SARG谓词和数据类型：选择使用整数参数
declare
@IntParam int = '200'
select * from dbo.Data where VarcharKey = @IntParam;
select * from dbo.Data where VarcharKey = convert(varchar(10),@IntParam);
如图2-14所示，对于整数参数，SQL Server扫描聚簇索引，将varchar转换为每行的整数。 在第二种情况下，SQL Server在开始时将整数参数转换为varchar，并使用更高效的聚簇索引查找操作。
图2-14。 SARG谓词和数据类型：带整数参数的执行计划
注意：请注意连接谓词中的列数据类型。 隐式或显式数据类型转换可能会显着降低查询的性能。
在unicode字符串参数的情况下，您将观察到非常类似的行为。 让我们运行清单2-8中所示的查询。 图2-15显示了语句的执行计划。
Listing 2-8. SARG predicates and data types: Select with string parameter
清单2-8 SARG谓词和数据类型：使用字符串参数选择
select * from dbo.Data where VarcharKey = '200';
select * from dbo.Data where VarcharKey = N'200'; -- unicode parameter
如您所见，对于varchar列，unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为unicode。 因此，除非将参数数据类型显式指定为varchar，否则SQL Server客户端库会为字符串对象生成unicode（nvarchar）参数。 这使得谓词不具有SARG，并且由于不必要的扫描，它可能导致主要的性能命中，即使对varchar列进行索引也是如此。
注意：始终在客户端应用程序中指定参数数据类 例如，在ADO.Net中使用
在unicode字符串参数的情况下，您将观察到非常类似的行为。运行清单2-8中所示的查询。 图2-15显示了语句的执行计划。
清单2-8 SARG谓词和数据类型：使用字符串参数选择
select * from dbo.Data where VarcharKey = '200';
select * from dbo.Data where VarcharKey = N'200'; -- unicode parameter
图2-15。 S ARG谓词和数据类型：带有参数的执行计划
如您所见，对于varchar列，unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为unicode。 因此，除非将参数数据类型显式指定为varchar，否则SQL Server客户端库会为字符串对象生成unicode（nvarchar）参数。 这使得谓词不具有SARG，并且由于不必要的扫描，它可能导致不能搜索，即使对varchar列进行索引也是如此。
注意：始终在客户端应用程序中指定参数数据类 例如，在ADO.Net中使用
在ORM框架中使用映射来显式指定类中的非unicode属性。
值得一提的是，对于nvarchar unicode数据列，varchar参数是SARGable。
表和索引:内部结构和访问方法
图 2 – 4。转发指针和I/O:存在转发指针时读取数据
大量转发指针导致额外的I/O操作，并显著降低了访问数据的查询的性能。本书的配套材料包括在大范围内用包含大量数据的表演示这个问题的脚本。
当转发行的大小被另一次更新减少，并且带有转发指针的数据页有足够的空间容纳更新后的行版本时，SQL Server可能会将其移动回原来的数据页并删除转发指针行。然而，摆脱所有转发指针的唯一可靠方法是重新构建堆表。您可以通过使用ALTER TABLE REBUILD语句来实现这一点。
堆表在登台环境中非常有用，在登台环境中，您希望尽可能快地将大量数据导入系统。将数据插入堆表通常比将数据插入具有聚集索引的表更快。然而，在常规工作负载期间，具有聚集索引的表通常优于堆表，堆表具有次优空间控制和通过转发指针引入的额外I/O操作。
聚集索引
一个聚集索引指示表中数据的物理顺序，表按照聚集索引键进行排序。表只能定义一个聚集索引。
让我们假设您希望在堆表上使用数据创建一个聚集索引。作为第一步，如图2-5所示，SQL Server创建数据的另一个副本，然后根据聚集键的值对数据进行排序。数据页链接在一个双链列表中，其中每个页面都包含指向链中的下一个和前一个页面的指针。这个列表称为索引的叶级，它包含实际的表数据。
图 2 - 5。聚类索引结构:叶级
注意：页面上的排序顺序由插槽阵列控制。页面上的实际数据未排序。
当叶子级别由多个页面组成时，SQL Server开始构建索引的中间级别，如图2-6所示。
图2-6。聚集索引的结构：中间级别和叶子级别
中间级别为每个叶级页面存储一行。它存储两条信息：物理地址和引用的页面中的索引键的最小值。唯一的例外是第一页上的第一行，其中SQL Server存储NULL而不是最小索引键值。有了这样的优化，SQL插入时，服务器不需要更新非叶子级别行表中键值最小的行。页面的中间级别也链接到双链表。 SQL服务器添加越来越多的中间级别，直到有一个仅包括单页级别。此级别称为根级别，它成为索引的入口点，如图所示图2-7。
图2-7. 聚集索引结构：根级别
如您所见，索引始终有一个叶子级别，一个根级别，和零个或多个中间级别。唯一的不同是什么时候索引数据适合单个页面。在这种情况下，SQL Server不会创建单独的根级别页面，索引由单叶子级别页面组成。索引中的级别数量主要取决于行和索引键大小。例如，索引就可以了4字节整数列每行需要13个字节中级和根级。这13个字节由一个2字节的插槽组成 数组条目，4字节索引键值，6字节页面指针和1-字节行开销，这是足够的，因为索引键没有包含可变长度和NULL列。结果，你可以容纳8,060字节/每行13字节=每页620行。这意味着，通过一个中间级别，您可以存储信息大约620 * 620 = 384,400个叶子级页面。如果数据行大小为200字节，每个叶级页面最多可存储40行索引中有15,376,000行，只有三个级别。添加另一个指数的中间级别基本上涵盖所有可能的整数值。
注意：在现实生活中，索引碎片会减少这些碎片数字。我们将在第6章讨论索引碎片。
SQL Server可以通过三种不同的方式从中读取数据指数。第一个是有序扫描。让我们假设我们想要运行SELECT Name FROM dbo.Customers ORDER BY CustomerId查询。索引的叶级别上的数据已经基于排序在CustomerId列值上。因此，SQL Server可以扫描索引的叶级从第一页到最后一页并返回行按存储顺序排列。
SQL Server从索引的根页开始并从中读取第一行。该行引用了中间页面表中的最小键值。 SQL Server读取该页面和重复该过程，直到找到叶子级别的第一页。然后，SQL Server开始逐个读取行，通过链接列表的页面，直到读取所有行。图2-8说明了这个过程。
图2-8。有序索引扫描
上一个查询显示了聚集索引将Ordered属性设置为true的运算，如下图2-9所示。
图2-9。有序索引扫描执行计划
值得一提的是，排序不是必需的要触发的有序扫描。有序扫描只意味着SQL服务器根据索引键的顺序读取数据。SQL Server可以向前和向后扫描两个方向的索引。但是，必须牢记一个重要方面：SQL在反向索引扫描期间，服务器不使用并行性。
注意：您可以通过检查索引扫描来检查扫描方向或执行计划中的索引运算符属性。但是，请注意，Management Studio不会显示这些内容执行计划的图形表示中的属性。您需要打开“属性”窗口以通过选择运算符来查看它在执行计划中并选择“视图/属性窗口”菜单项目或按F4键。
SQL Server企业版具有优化的功能称为旋转木马扫描，允许多个任务共享相同的索引扫描。让我们假设您有会话S1，即扫描索引。在扫描中间的某个点，另一个会话S2运行需要扫描相同索引的查询。有了旋转木马扫描，S2在其当前扫描位置加入S1。 SQL服务器只读取每个页面一次，将行传递给两个会话。
当S1扫描到达索引的结束时，S2从索引的开始开始扫描数据，直到S2扫描开始的点。旋转木马扫描是另一个示例，它说明了为什么您不能依赖于索引键的顺序，以及为什么在需要时应该始终指定ORDER BY子句。排序扫描之后的下一个访问方法称为分配顺序扫描。S QL Server通过IAM页面访问表数据，类似于使用堆表的方式。SELECT Name from dbo.Customers WITH(NOLOCK)查询和图2-10说明了这种方法。图2-11显示了查询执行计划。
图2-10。分配顺序扫描
图2-11。分配顺序扫描执行计划
不幸的是，SQL Server使用时很难检测分配顺序扫描。即使在Ordered属性的执行计划显示false，表示SQL Server不关心是否按索引键的顺序读取行，而不是使用了分配订顺序扫描。
扫描大表时，分配顺序扫描可以更快，虽然它具有更高的启动成本。 当表很小时SQL Server不使用它当访问方法。另一个重要的考虑是数据一致性。SQL Server不使用转发指针，具有聚集索引的表和分配顺序扫描可以产生不一致的结果。由于分页导致的数据移动，可以多次跳过或读取行。因此，SQLServer通常避免使用分配顺序扫描。除非它以READ UNCOMMITTED或SERIALIZABLE事务隔离级别读取数据。
注意：我们将在第6章“索引分段”中讨论分页和分段，在第三部分“锁定、阻塞和并发”中讨论锁定和数据一致性。
最后一个索引访问方法称为索引查找。 SELECT名称FROM dbo.Customers WHERE CustomerId BETWEEN 4 AND 7查询.图2-12说明了该操作
图2-12。索引查找
为了从表中读取行的范围，SQL Server需要从范围中找到具有最小键值的行是4. SQL Server以根页面开始，其中第二行引用最小键值为350的页面。它大于我们要查找的键值（4），并且SQL Server读取根页面上第一行引用的中间级数据页（1：170）。
同样，中间页面将SQL Server引向第一个叶子 - 级别页面（1：176）。 SQL Server读取该页面，然后读取行CustomerIds等于4和5，最后，它读取两个第二页的剩余行。
执行计划如图2-13所示。
图2-13。索引查找执行计划
您可以猜测，索引搜索比索引扫描更有效，因为SQL Server只处理行和数据页的子集，而不是扫描整个表。
从技术上讲，索引搜索操作有两种。第一种称为单例查找，有时称为点查找，其中SQL Server寻找并返回单行。您可以考虑将WHERE CustomerId = 2谓词作为示例。另一种类型的索引查找操作称为范围扫描，它要求SQL Server查找键的最低值或最高值，并扫描（向前或向后）行集，直到达到扫描范围的末尾。 CustomerId BETWEEN 4和7之间的谓词WHERE导致范围扫描。这两种情况都在执行计划中显示为INDEX SEEK操作。
可以猜到，范围扫描完全可以强制SQL Server处理索引中的大量甚至所有数据页。例如，如果您将查询更改为使用WHERE CustomerId> 0谓词，则SQL Server将读取所有行/页，即使您在执行计划中显示了Index Seek运算符。您必须牢记此行为，并始终在查询性能调整期间分析范围扫描的效率。
关系数据库中有一个名为SARGable谓词的概念，它代表Search Argumentable。如果索引存在，如果SQL Server可以使用索引查找操作，则谓词是SARGable。简而言之，当SQL Server可以隔离要处理的索引键值的单个值或范围时，谓词是SARGable，因此在谓词评估期间限制搜索。显然，使用SARGable谓词编写查询并尽可能利用索引查找是有益的。 SARGable谓词包括以下运算符：=，>，> =，<，<=，IN，BETWEEN和LIKE（在前缀匹配的情况下）。非SARGable运算符包括NOT，<>，LIKE（在非前缀匹配的情况下）和NOT IN。使谓词非SARGable的另一种情况是对表列使用函数或数学计算。 SQL Server必须为其处理的每一行调用该函数或执行计算。幸运的是，在某些情况下，您可以重构查询以使这样的谓词成为SARGable。
表2-1列出了一些例子。
表2-1。 将非SARGable谓词重构为SARGable的示例
另一个重要因素是类型转换。 在某些情况下，您可以使用不正确的数据类型使谓词非SARGable。让我们创建一个带有varchar列的表，并用一些数据填充它，如清单2-6所示。
清单2-6 SARG谓词和数据类型：测试表创建
create table dbo.Data
(
VarcharKey varchar(10) not null,
Placeholder char(200)
);
create unique clustered index IDX_Data_VarcharKey
on dbo.Data(VarcharKey);
;with N1(C) as (select 0 union all select 0) -- 2 rows
,N2(C) as (select 0 from N1 as T1 cross join N1 as T2) -- 4 rows
,N3(C) as (select 0 from N2 as T1 cross join N2 as T2) -- 16 rows
,N4(C) as (select 0 from N3 as T1 cross join N3 as T2) -- 256 rows
,N5(C) as (select 0 from N4 as T1 cross join N4 as T2) -- 65,536 rows
,IDs(ID) as (select row_number() over (order by (select null)) from N5)
insert into dbo.Data(VarcharKey)
select convert(varchar(10),ID) from IDs;
聚集索引键列定义为varchar，用它存储整数值。现在，让我们运行两个选择，如清单2-7所示，并查看执行计划。
Listing 2-7. SARG predicates and data types: Select with integer parameter
清单2-7 SARG谓词和数据类型：选择使用整数参数
declare
@IntParam int = '200'
select * from dbo.Data where VarcharKey = @IntParam;
select * from dbo.Data where VarcharKey = convert(varchar(10),@IntParam);
如图2-14所示，对于整数参数，SQL Server扫描聚簇索引，将varchar转换为每行的整数。 在第二种情况下，SQL Server在开始时将整数参数转换为varchar，并使用更高效的聚簇索引查找操作。
图2-14。 SARG谓词和数据类型：带整数参数的执行计划
注意：请注意连接谓词中的列数据类型。 隐式或显式数据类型转换可能会显着降低查询的性能。
在unicode字符串参数的情况下，您将观察到非常类似的行为。 让我们运行清单2-8中所示的查询。 图2-15显示了语句的执行计划。
Listing 2-8. SARG predicates and data types: Select with string parameter
清单2-8 SARG谓词和数据类型：使用字符串参数选择
select * from dbo.Data where VarcharKey = '200';
select * from dbo.Data where VarcharKey = N'200'; -- unicode parameter
如您所见，对于varchar列，unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为unicode。 因此，除非将参数数据类型显式指定为varchar，否则SQL Server客户端库会为字符串对象生成unicode（nvarchar）参数。 这使得谓词不具有SARG，并且由于不必要的扫描，它可能导致主要的性能命中，即使对varchar列进行索引也是如此。
注意：始终在客户端应用程序中指定参数数据类 例如，在ADO.Net中使用
在unicode字符串参数的情况下，您将观察到非常类似的行为。运行清单2-8中所示的查询。 图2-15显示了语句的执行计划。
清单2-8 SARG谓词和数据类型：使用字符串参数选择
select * from dbo.Data where VarcharKey = '200';
select * from dbo.Data where VarcharKey = N'200'; -- unicode parameter
图2-15。 S ARG谓词和数据类型：带有参数的执行计划
如您所见，对于varchar列，unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为unicode。 因此，除非将参数数据类型显式指定为varchar，否则SQL Server客户端库会为字符串对象生成unicode（nvarchar）参数。 这使得谓词不具有SARG，并且由于不必要的扫描，它可能导致不能搜索，即使对varchar列进行索引也是如此。
注意：始终在客户端应用程序中指定参数数据类 例如，在ADO.Net中使用
在ORM框架中使用映射来显式指定类中的非unicode属性。
值得一提的是，对于nvarchar unicode数据列，varchar参数是SARGable。
rom dbo.Data where VarcharKey = N'200'; -- unicode parameter
图2-15。 S ARG谓词和数据类型：带有参数的执行计划
如您所见，对于varchar列，unicode字符串参数是非SARGable。 这是一个比看起来更大的问题。 虽然您很少以这种方式编写查询，如清单2-8所示，但现在大多数应用程序开发环境都将字符串视为unicode。 因此，除非将参数数据类型显式指定为varchar，否则SQL Server客户端库会为字符串对象生成unicode（nvarchar）参数。 这使得谓词不具有SARG，并且由于不必要的扫描，它可能导致不能搜索，即使对varchar列进行索引也是如此。
注意：始终在客户端应用程序中指定参数数据类 例如，在ADO.Net中使用
在ORM框架中使用映射来显式指定类中的非unicode属性。
值得一提的是，对于nvarchar unicode数据列，varchar参数是SARGable。
原著《Pro SQL Server Internals, 2nd edition》的CHAPTER 1 Data Storage Internals中的Data Pages and Data Rows一节
223
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
