sqlserver索引

转载自： https://www.cnblogs.com/knowledgesea/p/3672099.html 索引的概念 索引的用途：我们对数据查询及处理速度已成为衡量应用系统成败的标准，而采用索引来加快数据处理速度通常是最普遍采用的优化方法。 索引是什么：数据库中的索引类似于一本书的目录，在一本书中使用目录可以快速找到你想要的信息，而不需要读完全书。在数据库中，数据库程序使用索引可以重啊到表中的数据，而不必扫描整个表。书中的目录是一个字词以及各字词所在的页码列表，数据库中的索引是表中的值以及各值存储位置的列表。 索引的利弊：查询执行的大部分开销是I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读取表的每一个数据页，如果有索引指向数据值，则查询只需要读少数次的磁盘就行啦。所以合理的使用索引能加速数据的查询。但是索引并不总是提高系统的性能，带索引的表需要在数据库中占用更多的存储空间，同样用来增删数据的命令运行时间以及维护索引所需的处理时间会更长。所以我们要合理使用索引，及时更新去除次优索引。 数据表的基本结构 一个新表被创建之时，系统将在磁盘中分配一段以8K为单位的连续空间，当字段的值从内存写入磁盘时，就在这一既定空间随机保存，当一个 8K用完的时候，数据库指针会自动分配一个8K的空间。这里，每个8K空间被称为一个数据页（Page）

SqlServer索引的原理与应用 索引的概念 索引的用途：我们对数据查询及处理速度已成为衡量应用系统成败的标准，而采用索引来加快数据处理速度通常是最普遍采用的优化方法。 索引是什么：数据库中的索引类似于一本书的目录，在一本书中使用目录可以快速找到你想要的信息，而不需要读完全书。在数据库中，数据库程序使用索 引可以重啊到表中的数据，而不必扫描整个表。书中的目录是一个字词以及各字词所在的页码列表，数据库中的索引是表中的值以及各值存储位置的列表。 索引的利弊：查询执行的大部分开销是I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读取表的每一个数据页，如果有 索引指向数据值，则查询只需要读少数次的磁盘就行啦。所以合理的使用索引能加速数据的查询。但是索引并不总是提高系统的性能，带索引的表需要在数 据库中占用更多的存储空间，同样用来增删数据的命令运行时间以及维护索引所需的处理时间会更长。所以我们要合理使用索引，及时更新去除次优索引。 数据表的基本结构 一个新表被创建之时，系统将在磁盘中分配一段以8K为单位的连续空间，当字段的值从内存写入磁盘时，就在这一既定空间随机保存，当一个 8K用完的时候，数据库指针会自动分配一个8K的空间。这里，每个8K空间被称为一个数据页（Page），又名页面或数据页面，并分配从0-7的页号, 每个文件的第0页记录引导信息，叫文件头

在应用系统中，尤其在联机事物处理系统中，对数据查询及处理速度已成为衡量应用系统的标准。 而采用索引来加快数据处理速度也成为广大数据库用户所接受的优化方法。 在良好的数据库设计基础上，能够有效地索引是SQL Server取得高性能的基础,SQL Server采用基于代价的优化模型,他对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部门开销是磁盘I/O，使用索引提高性能的一个主要目标就是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需要读几次磁盘就能了。所以如果建立了合理的索引，优化器就能利用索引加速数据的查询过程。不过，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引和程式结合起来，才能产生最佳的优化方案。本文就是SQL Server索引的性能问题进行了一些分析和实践。 一、聚集索引(clustered indexes)的使用 聚集索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面，所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快。

索引碎片： 内部碎片（或说叶级填充率）：反映数据叶级的空间占用率或空闲率 外部碎片：由于sqlserver以连续的8个page作为一个数据库块（区）extent作为读取单位，故此由于物理存储上的区和逻辑上不一致（不连续）而造成io读取切换 逻辑碎片：这是索引的叶级页中出错页所占的百分比。对于出错页，分配给索引的下一个物理页不是由当前叶级页中的“下一页”指针所指向的页 区碎片：这是堆的叶级页中出错区所占的百分比。出错区是指：包含堆的当前页的区不是物理上的包含前一页的区后的下一个区。（微软真不会解释概念:( 查询碎片情况： 　　dbcc showcontig：四部分对象名，【索引名】|【索引id】 　　dbcc showcontig：当前库对象id，【索引名】|【索引id】　　　　 　　sys.dm_db_index_physical_stats：数据库id，对象id，索引id，分区id，扫描模式 五个参数，基本上，【0（特殊的，index可以为0，故该处为-1）】|【null】|【default】 意义是一样的 基本指标： 扫描密度（%）[最佳计数:实际计数]：这是“最佳计数”与“实际计数”的比率。如果所有内容都是连续的，则该值为 100；如果该值小于 100，则存在一些碎片。“最佳计数”是指在一切都连续链接的情况下，区更改的理想数目。“实际计数”是指区更改的实际次数。 逻辑扫描碎片

SQLSERVER中的假脱机spool 我发现网上对于假脱机的解释都非常零散，究竟假脱机是什么？ 这几天在家里研究了一下，收集了很多网上的资料 假脱机是中文的翻译，而英文的名字叫做 spool 在徐老师写的《SQLSERVER企业级平台管理实践》里提到了一下假脱机 在SQLSERVER I/O问题的那一节 在性能监视器里，有一个计数器“worktables/sec” ： 每秒创建的工作表数。例如，工作表可用于存储查询 假脱机 （query spool），LOB变量，XML变量，表变量，游标的临时结果 在《剖析SQLServer执行计划》里也提到了假脱机 (13) 有时查询优化器需要在tempdb数据库中建立临时工作表。如果是这样的话 就意味着图形执行计划中有标识成 Index Spool， Row Count Spool 或者 Table Spool 的图标。 任何时候，使用到工作表一般都会防碍到性能，因为需要额外的I/O开销来维护这个工作表。 之前本人也写过一篇文章： 对于索引假脱机的一点理解 写这篇文章的时候当时还是对假脱机一知半解 假脱机在MSDN中的执行计划中的逻辑运算符和物理运算符中提到了几个假脱机相关的运算符（详见本文最后面） Eager Spool Lazy Spool Index Spool (有时候也叫 Nonclustered Index Spool ) Row

SQLSERVER聚集索引和主键的误区 很多人会把Primary Key和聚集索引搞混起来，或者认为这是同一个东西。这个概念是非常错误的。 主键是一个约束（constraint），他依附在一个索引上，这个索引可以是聚集索引，也可以是非聚集索引。 所以在一个（或一组）字段上有主键，只能说明他上面有个索引，但不一定就是聚集索引。 例如下面： 1 USE [pratice] 2 GO 3 CREATE TABLE #tempPKCL 4 ( 5 ID INT PRIMARY KEY CLUSTERED --聚集索引 6 ) 7 8 9 --------------------------------- 10 USE [pratice] 11 GO 12 CREATE TABLE #tempPKNCL 13 ( 14 ID INT PRIMARY KEY NONCLUSTERED --非聚集索引 15 ) 16 17 18 DROP TABLE [#tempPKCL] 19 DROP TABLE [#tempPKNCL] 如果不加 NONCLUSTERED 和 CLUSTERED 关键字，默认建的是聚集索引 而一个聚集索引里，是可以有重复值的。只要他没有被同时设为主键，但是主键不能有重复值（不管依附在聚集索引上还是非聚集索引上） 强调这一点，是因为有些人觉得自己的表格上设置了主键

原文: 性能调优6：Spool 假脱机调优 SQL Server的Spool（假脱机）操作符，用于把前一个操作符处理的数据（又称作中间结果集）存储到一个隐藏的临时结构中，以便在执行过程中重用这些数据。这个临时结构都创建在tempdb中，通常的结构是工作表（worktable）和工作文件（workfile）。假脱机运算符会取出表或索引结构中的一部分的数据集，将他们存放在tempdb数据库的临时结构里，我推测：如果这个临时结构用于存储表数据，称作worktable；如果这个临时结构存储的是Hash表，称作workfile。 SQL Server使用Spool操作符的优点是： 数据或中间结果集会被多次重用 使假脱机数据与源数据保持隔离 一，Spool操作的分类 在执行计划中，Eager Spool和Lazy Spool是逻辑操作符，这两个逻辑操作符之间的区别是： Eager Spool：一次性把所有数据存储到临时结构中，它是一个阻塞性的操作符，这意味着它需要读取输入中的所有数据，然后处理完所有的数据行之后，才向下一个操作符返回结果，也就是说，除非Eager Spool把所有的数据行都处理完成，否则无法访问到这些数据。 Lazy Spool：逐行把数据存储到临时结构中，它是一个非阻塞性的操作符，这意味着它可以边读取数据，边向下一个操作符输出数据，也就是说，在Lazy

微软官网上的解释： 索引是与表或视图关联的磁盘上结构，可以加快从表或视图中检索行的速度。 索引包含由表或视图中的一列或多列生成的键。 这些键存储在一个结构（B 树）中，使 SQL Server 可以快速有效地查找与键值关联的行。 表或视图可以包含以下类型的索引： 聚集 聚集索引根据数据行的键值在表或视图中排序和存储这些数据行。 索引定义中包含聚集索引列。 每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。 只有当表包含聚集索引时，表中的数据行才按排序顺序存储。 如果表具有聚集索引，则该表称为聚集表。 如果表没有聚集索引，则其数据行存储在一个称为堆的无序结构中。 非聚集 非聚集索引具有独立于数据行的结构。 非聚集索引包含非聚集索引键值，并且每个键值项都有指向包含该键值的数据行的指针。 从非聚集索引中的索引行指向数据行的指针称为行定位器。 行定位器的结构取决于数据页是存储在堆中还是聚集表中。 对于堆，行定位器是指向行的指针。 对于聚集表，行定位器是聚集索引键。 可以向非聚集索引的叶级添加非键列以跳过现有的索引键限制，并执行完整范围内的索引查询。 聚集索引和非聚集索引都可以是唯一的。 这意味着任何两行都不能有相同的索引键值。 另外，索引也可以不是唯一的，即多行可以共享同一键值。 实际上，可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引

sqlserver性能优化之索引的使用和优化 在应用系统中,尤其在联机事务处理系统中,对数据查询及处理速度已成为衡量应用系统成败的标准。而采用索引来加快数据处理速度也成为广大数据库用户所接受的优化方法。 在良好的数据库设计基础上，能有效地使用索引是SQL Server取得高性能的基础，SQL Server采用基于代价的优化模型，它对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部分开销是磁盘I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需读几次磁盘就可以了。所以如果建立了合理的索引，优化器就能利用索引加速数据的查询过程。但是，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。本文就SQL Server索引的性能问题进行了一些分析和实践。 一、聚簇索引(clustered indexes)的使用 　　聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面

SQLSERVER SQL 性能优化系列　　 　　 1. 选择最有效率的表名顺序 ( 只在基于规则的优化器中有效 ) 　　 　　 SQLSERVER 的解析器按照从右到左的顺序处理 FROM 子句中的表名，因此 FROM 子句中写在最后的表（基础表 driving table ）将被最先处理，在 FROM 子句中包含多个表的情况下，必须选择记录条数最少的表作为基础表，当 SQLSERVER 处理多个表时，会运用排序及合并的方式连接它们， 　　 首先，扫描第一个表（ FROM 子句中最后的那个表 ) 并对记录进行排序；然后扫描第二个表（ FROM 子句中最后第二个表 ) ；最后将所有从第二个表中检索出的记录与第一个表中合适记录进行合并 　　 例如 : 表 TAB1 16,384 条记录表 TAB2 5 条记录，选择 TAB2 作为基础表 ( 最好的方法 ) select count(*) from tab1,tab2 执行时间 0.96 秒，选择 TAB2 作为基础表 ( 不佳的方法 ) select count(*) from tab2,tab1 执行时间 26.09 秒； 如果有 3 个以上的表连接查询，那就需要选择交叉表（ intersection table ）作为基础表，交叉表是指那个被其他表所引用的表　　 　　 例如 : 　　 EMP 表描述了 LOCATION 表和