基于索引的SQLServer查询性能优化错误分析

据了解，对指标的理解绝大多数开发者都是一知半解，局限于最日常的工作没有机会，也不需要关心，知道什么是索引，一天一个查询太慢找到查询的好的指标，这一速度慢的问题，然后建立一个索引，或者干脆把整个查询直接SQL DBA，让DBA直接帮助优化，这样的情况是，理解为指标的开发商，了解非常有限，我采取了以下的个人理解，你认识浅指数和分享，希望解除一些你的疑惑，错误在一起的指数

错误1。在表上建立索引。索引将在查询使用时使用，索引将生效。
首先，弄清这种观点是错误的。SQLServer查询优化器是基于开销选择的优化器。确定是否使用索引或索引和使用索引通过一系列复杂的judgements.sql服务器维护索引列的数据统计，并与索引列的内容统计变化。索引的有效性完全取决于索引列上的统计信息。随着数据的变化，索引机制也发生了变化。查询优化器总是查询成本最低的永远是最好的选择，如果一个非聚集索引有大量重复值的列，那么指数不会有什么存在的意义，这就是为什么不推荐在相似性，为非聚集索引以上点理由。

这里可能有疑问，我在性别上建立了一个索引列，性别只有两个值的男女，当我们在这个领域有性别的查询条件时，至少可以过滤掉一半的数据，可以大大减少，我们需要检索数据，怎么会不使用呢（事实上，这是我很困惑的地方），对我们理解，例如，基于性别性别列索引ix_gender用户表、用户性别= 'select男性性别，查询效率很高，但也成功地应用ix_gender指数，但当我们写SQL那么点，我们会写SQL：选择用户名，用户名，电话，从用户性别=凸出然后查看查询计划不使用索引ix_gender电子邮件，但聚集索引扫描或扫描表，其中性别=凸出的明确定义的ix_gender查询，为什么不使用它所有的罪恶之源，是书签查找（RID，关键字搜索，好）没有书签查找我们要讨论的话题，在这里只是想告诉你，这个指标是不是万能的ING，该指数不是为了有效而设立的。

误区2。聚合索引扫描使用聚合索引索引，因此性能非常高。
一般来说，我们可以得出这样的结论：聚集索引是最有效的指标，但对聚集索引扫描是没有效率的代表，聚集索引扫描是一个表扫描，扫描的话，一般出现在一个指数或指数代表的缺乏是无效的，所以我们应该避免看到在查询计划扫描文字的日常应用，更聚集索引搜索真的搜索索引的索引的使用，才是王道。

误区3。聚合索引扫描（表扫描）是全表扫描，因此只要表扫描的出现是低性能的某种表示。
2我们应该尽量避免犯错误的时候，聚集索引扫描或扫描表，这是我们必须坚持的原则，但这并不意味着会有一个表扫描性能较低，在某些情况下，而不是索引查找表扫描具有更高的效率（一般回报大量的数据，大量的书签查找的情况下）

Misunderstandings 4. 查询计划在查看键查找或清除查找时具有很高的性能。
密钥查找和删除查找统称为书签查找，这与错误识别正好相反。书签查找意味着低性能。在某些情况下，它甚至比表扫描效率低。因此，我们应该尽量避免书签查找，返回的数据量小，书签查找对性能的影响不大，如果返回的数据量大，书签查找会严重影响查询性能，所以我们应该建立指标覆盖返回所有列，当然，列的索引数量是有限的，不只是为了避免在索引中的书签查找包含大量的列可以用来解决覆盖索引书签查找的问题，或需要大量的数据恢复使用聚簇索引；和常听为什么不使用SELECT *，只有选择列输出，因为选择是引起bookmar很容易在我们不玩之后，可以在所有列中建立索引，不能使用聚集索引（使用书签查找聚集索引和表扫描时间）进行所有查询。

误区5。查询开销统计数据中逻辑读取的数量是读取的记录数。
我还天真的以为如此，查询计划是读取记录，逻辑读的数量，但是，看到我们4.1全表扫描的查询返回830行数据，为什么逻辑读只有22次，而4.5是相同的查询返回830行数据，逻辑读1724次为什么，一旦读什么逻辑读22次最多22行数据，逻辑读1724字应该回归到1724的数据，有点晕，这里解释是指逻辑读取数页阅读，一本8页的64kb 8KB，构成一个地区，例如，表22页保存所有我们的数据，所以表扫描仅读22遍，4.5查询1724次为什么读它，甚至如果一个网页是一个数据块是最800次也可以读，这我因为，最小单位QL服务器读取数据读取一个页面，即使数据还需要阅读整页的数据，而非聚集索引读取随机读取更多的记录将导致重复阅读同一页上，再加上书签查找导致了这么多的逻辑读取，这就是为什么非聚集索引是不适合一个原因读取大量数据。
我们使用Northwind数据库表订单表为例

1。首先删除订单表的所有索引
4。创建一个聚集索引的行的索引列，行
复制代码代码如下所示：
创建聚集索引ix_orderid订单（订单号）

三.创建非聚集索引ix_orderdate订单表

创建订单指数ix_orderdate（订单）
4。设置查询分析器包含实际的执行计划（右击>包含实际的执行计划），打开IO统计数据，然后依次执行以下查询
复制代码代码如下所示：
设置统计数据
从订单中选择*
SELECT * FROM订单，订单< = '1996-7-10
SELECT * FROM订单，订单< = '1997-1-1

-迫使指数ix_orderdate查询日期1997-1-1使用
SELECT * FROM命令（指数= ix_orderdate）在OrderDate <= '1997-1-1

-迫使指数ix_orderdate查询天2000-1-1使用
SELECT * FROM命令（指数= ix_orderdate）在OrderDate <= '2001-1-1

4.1从订单中执行SELECT *的查询开销和查询计划
在不使用索引的情况下，可以看到执行聚合索引扫描、逻辑读取22次，并返回830行的行数。
U3000 U3000 U3000 U3000

4.2查询开销执行SELECT * FROM订单，订单< = '1996-7-10
你可以看到，指数ix_orderdate建立在订单已成功应用，逻辑读取数是14，和行数返回6行。

U3000 U3000

4.3查询开销和执行SELECT * FROM订单，订单< = '1997-1-1查询计划
我们可以看到，虽然在ix_orderdate OrderDate的指标建立，但执行计划不使用ix_orderdate指数但执行聚集索引扫描，和逻辑读取数22和4.2之间的差异只查询订单的价值是不一样的，返回的行数154
U3000 U3000
4.4查询开销和执行SELECT * FROM订单查询计划（指数= ix_orderdate）在OrderDate <= '1997-1-1
您可以看到，查询条件与4.3完全相同。我们被迫使用ix_orderdate，返回的记录数是完全一样的4.3。但读取的逻辑达到328次，并返回到154行。
U3000 U3000 U3000 U3000 U3000 U3000 U3000 U3000

4.5执行SELECT * FROM命令（指数= ix_orderdate）在OrderDate <= '2001-1-1'query开销和查询计划

我们也迫使指数ix_orderdate使用，查询条件发生了变化，逻辑读达到了1724次，和返回的行数为830行。
U3000 U3000 U3000 U3000

U3000 U3000 U3000 U3000
查询统计
SQL查询
索引
返回的行数
逻辑读取次数

4.1从订单中选择*
聚集索引扫描
八百三十
二十二

4.2选择*从订单，订单< = '1996-7-10
ix_orderdate
六
十四

4.3选择*从订单，订单< = '1997-1-1
聚集索引扫描
一百五十四
二十二

4.4选择*从订单（指数= ix_orderdate）在OrderDate <= '1997-1-1
ix_orderdate强制使用的
一百五十四
三百二十八

4.5选择*从订单（指数= ix_orderdate）在OrderDate <= '2001-1-1
ix_orderdate强制使用的
八百三十
一千七百二十四

通过比较上面的查询，我们可以知道，虽然我们已经建立索引，但是索引并不总是有效的。强制使用索引只会带来更低的效率。查询优化器将根据索引列的统计信息自动选择最佳的查询计划。4.3和4.4查询的查询条件完全一样，虽然我们已经建立了索引ix_orderdate，但查询优化器不使用较低开销的聚集索引扫描的选择，我们用逻辑而不是激增强制性指标查询成本读22倍至328倍，而我们只是检查在154排；查询4.5我们继续强制使用索引，在查询返回的变化值，830行的逻辑读取数条件下的数据达到了1724次，并返回相同的数据查询4.1只有22个逻辑执行读取。

困惑：通过查询4.1，我们知道订单表中只有830个数据。为什么我们在4.5读取索引，在读取强制索引之后，逻辑读取达到1724次。即使一个数据只读取一次，它也只有830次。

常见问题：4.5强制使用索引查询，对ix_orderdate检索索引的查询优化器，再根据指标在ix_orderdate根据聚集索引指针找到聚集索引、聚集索引的叶节点的指针（实际数据）找到数据（图书搜索），从而导致更大的查询成本。

结论：
1。索引不是万能药。索引不代表查询列上的索引（见结论2）。
2。在大多数情况下，查询优化器根据索引上的一列数据统计信息自动选择最优执行计划，而查询计划会随着数据量的变化而变化，因此如果没有必要使用索引提示来强制使用索引。
3、聚集索引扫描和表扫描并不一定效率低下。在表扫描中没有书签查找。当使用非聚集索引返回大量行时，如果有书签查找，则不如表扫描性能好。
4。索引查找不一定效率高（在非聚集索引查找时很容易出现书签查找）
5、书签查找将降低查询效率。尤其是在大范围读取数据时，会严重影响效率，因此尽量避免书签查找或书签查找，并尽量少返回数据行。
6。需要注意的是，查询开销统计数据中的逻辑读取是读取的页数，而不是数据行的数目。

在例句和仅作为演示数据的使用，实际的开发和应用比样本数据更复杂，相同的查询可能在不同的环境下产生相反的结果，如何利用好这主要在于我们自己的理解，希望有看到这个朋友的快乐拿一些指标加深了解和理解，误解的指标，高性能的应用程序的开发。

我不是DBA，只是一个普通的开发者，首先，在实际工作中有些经验，鉴于我的水平很有限，没有理解或说不到位请上帝改正，以免误导别人，心存感激。

后续将继续编写SQL Server查询性能优化方面的实践经验，包括以下几个方面
建立合理的SQL Server查询性能优化指标
避免查询书签的SQL Server查询性能优化
SQL查询性能优化的重用查询计划
为SQL Server查询性能优化选择适当的字段类型

附：demodb.rar数据表

从Northwind数据库分离，只有订单表的方法。

这篇文章是《懒兔》的起源。