解析SQLServer焦点删除（书签查找、清除查找、键查找）
前言前面的部分是对本节内容的基础上，我们谈论指数的优化性能，在处理数据时，首先想到的是指标，一旦遇到这样的问题是混乱的，各种各样的信息搜索，为什么不扎实的基本功，我们简要内容，由浅入深更深，更深的理解，而不是一个盒子放死，立即给予解决，然后抛出问题，解决问题，你没有得到。
书签查找、删除查找、键查找定义
说到三，如果研究的指标不是很深，鞋力估计是无知的，什么东西，我们相信上面的三个翻译：ID搜索，搜索，标签键搜索。标签查找和键查找是一个意思，称为SQL 2005前的键查找。如何解释和如何定义它我们不想直接看的定义在下面的逐步分析，如果你真的无法帮助，请看公园{ }雍红的朋友认为，诠释的非常到位。我们简要解释的概念三。
在查询中，我们在查询条件列如果建立非聚集索引，这可能会尝试使用非聚集索引的搜索，如果返回列不创建非聚集索引将返回的数据页在这个时候获得这些列的数据，即使没有聚集索引或表，都将返回表或聚集索引获取数据。上述情况说明，如果表不创建聚集索引，则称为bookmar查找。如果表中没有聚集索引，但有一个非聚集索引，我们称之为取消查找。这就是我们在这一节中删除上面三部分来提高查询性能的原因。
抛出书签查找、清除查找、键查找问题
我们首先创建了下表
使用tsql2012
创建表销售订单
（
{行} int，
{ shipaddress } varchar（100），
{ ShipCity } varchar（100），
{ shipregion } varchar（100））
然后查询
使用tsql2012
选择行，shipaddress，shipregion
从销售订单
何为深圳
这不需要谈，没有添加索引，和查询计划的执行全表扫描，然后我们创建一个聚集索引行如下：
创建聚集索引idx_cls_orderid销售订单（订单号）。
我们再次执行上述查询。
此时，我们创建了聚合索引，因此这次查询转到聚合索引，在这里我们看到了由完整的表扫描转换为索引扫描的情况，我们在查询时总是有查询条件，但是我们没有对查询条件做任何操作。如果此时我们在查询条件上创建索引，那么查询的性能将得到提高，我们已经开始为查询条件创建一个非聚集索引。
创建销售订单（非聚集索引idx_nc_shipcity ShipCity）。
然后，我们再次执行查询。
我们观察到的查询条件来创建非聚集索引，查询计划将使用非聚集索引的搜索结果返回，但shipaddress，ShipCity，shipregion不是索引的一部分，搜索引擎会返回基表把这些数据再回来。这种行为称为书签查找或查找。下面我们做同样的问题作为本文要解决的问题的标题，删除书签查找或查找。我们试图在两种不同的方式解决它。
解决书签查找、删除查找、密钥查找等问题。
创建一个非聚合索引来覆盖索引
我们为查询条件和检索列创建一个非聚合索引。
创建销售订单（非聚集索引idx_all_cover。shipaddress，orderid，ShipCity，shipregion）
此时，我们将创建一个用于检索列的非聚集索引。那时，我们不会从数据页获取数据，而是直接从索引返回。所以我们在这里删除了键查找，但此时触发另一个问题，查询计划的执行是一个索引扫描。指数到底是多少让我们举个例子。索引相当于数据库中图书开头的索引。我们需要从书中快速找到我们需要的数据。在这个时候，这本书就是我们所说的表，索引扫描方式读取表中的所有行，然后返回所有满足条件的数据，当执行索引扫描，所有叶节点会被扫描，这意味着所有的行索引将再次检索代替索引表和表扫描对比如表扫描直接读取表中的数据，因此，表扫描和索引扫描是一个有点不同，但依赖于索引查找索引页的数据来定位所有的线条满足条件，找到符合条件的满足含线的页面的条件不仅影响指数，从而找到更有效的指标。
我们解释略下索引扫描和索引搜索，但问题是我们创建非聚集索引，但查询计划的执行是索引扫描，这是一个奇迹，只是我学习的指标，我不知道要做什么，那是因为缓存，缓存不太清楚。所以我开始怀疑是否在列的数据检索为空，或是否被复制或所列数据如下
创建非聚集索引idx_cls_cover上
销售订单（ShipCity，行，shipaddress，shipregion）
此时，如果我们修改查询条件如下。
使用tsql2012
选择行，shipaddress，shipregion
从销售订单
在shipaddress =深圳
这里我们应该发现唯一的区别是，当我们创建非聚集索引时，顺序和查询条件将导致索引扫描和索引查找转换。我们什么时候执行索引查找我们可以做以下一般性总结：
索引搜索的一般结论是，如果条件包含在或在上，查询条件必须放在索引集列中的第一位，然后将使用索引查找。
在这一点上，我们穿插了一些内容。在上面，我们创建了一个覆盖索引。我们比较了下一个覆盖索引和聚集索引查找的性能开销。
重叠索引与默认聚集索引的性能开销比较
从销售订单（指数（{ pk_orders }））
在<< 11072行
选择行，shipaddress，shipregion
从销售订单（指数（{ idx_noncls_include_exceptorderid }））
在<< 11072行
可以看出，覆盖索引的开销比默认的聚合索引性能的主键要好一点，我们可以看看下面两个IO成本。
通过将上述覆盖指数与默认聚集索引进行比较，我们可以有效地减少IO，这也是非常清楚的。当然，比较包含索引是另一个好计划。
创建包含非聚集索引
使用tsql2012
创建非聚集索引{ } { }（ix_noncls_include上tsql2012。{ } { }销售订单。
ShipCity
）包括（shipaddress，shipregion，orderId）
此时，我们通过使用索引和覆盖索引来删除书签查找、清除查找和键查找两种方式。
既然有两种方法，我们应该做出选择，谁有更好的表现呢然后我们比较上面两个的开销。
比较删除书签查找的两种方法
使用tsql2012
选择行，shipaddress，ShipCity，shipregion
从销售订单（指数（idx_all_cover））
何为深圳
选择行，shipaddress，ShipCity，shipregion
从销售订单（指数（ix_noncls_include））
何为深圳
我们知道，这两项费用没有差别，当然我们更倾向于采取第二种办法作为解决办法，这基本上是结束，但有一个小问题。我们已经创建了聚集索引的行之前。在后来的解决方案，我们还增加了非聚集索引的行。我们必须加上它吗让我们试试看。
创建非聚集索引idx_noncls_cover_exceptorderid
在销售订单（ShipCity，shipaddress，shipregion）
创建非聚集索引idx_noncls_include_exceptorderid
在销售订单（ShipCity）包括（shipaddress，shipregion）
删除行，两成本之间的差异：
使用tsql2012
选择行，shipaddress，shipregion
从销售订单（指数（{ idx_noncls_cover_exceptorderid }））
在shipaddress =深圳
选择行，shipaddress，shipregion
从销售订单（指数（{ idx_noncls_include_exceptorderid }））
在shipaddress =深圳
非聚集索引列不需要包含创建聚合索引的列，这是众所周知的事实吗
结论：实际上，不需要包含任何非聚集索引列来创建聚集索引，因为创建聚集索引列是列的非聚集索引集的一部分，也就是说，只要一个表列创建一个聚集索引，那么非聚集索引集列包含聚集索引。
总结
在这一节中，我们更详细地介绍了问题的解决方法，以便提高查询的性能，最后，我们将在下一节中再次。
以上就是本文的全部内容。希望本文的内容能给大家的学习或工作带来一定的帮助。如果有疑问，你可以留言交流，希望你能得到更多的支持。