智能书签

一、书签查找的观念

　　书签可以协助SQL SerZZZer快捷从非搜集索引条目导向到对应的止，其真那东西几多句话我就能说大皂。

　　假如表有搜集索引(区段构造)，这么书签便是从非搜集索引找到搜集索引后，操做搜集索引定位到数据。此处的书签便是搜集索引。假如表没有搜集索引(堆构造)。这么扫描非搜集索引后，通过RID定位到数据，这么此处书签便是RID。

　　所谓的书签查找，便是通过搜集索引，而后操做搜集索引或RID定位到数据。

　　不管默示堆构造还是区段构造，数据的寄存都是数据库文件的某文件->某页->某止，因而定位数据的文件组折起来便是
文件号:页号:止号。那三个数字便是RID。如文件1的第77页的第12止的RID便是1:77:12。

　　堆构造取区段构造差异，但凡堆上的止不会扭转位置，一旦他们被插入某个页中，他们就会接续正在这个位置。正在堆上的止很少挪动，假如止被挪动的话，他们会正在本来的位置留下指向其挪动到的新位置的指针。而区段构造的止，是可以挪动的，正在添加数据或整理索引时，都可以会被挪动位置。

　　因为正在堆上的止很少挪动，所以RID就可以惟一标识某一止，RID的值不只仅稳定，RID所默示的止的物理位置也不会变，那使得RID的值更适竞争为书签。那也是为什么SQL SerZZZer正在堆上建设的非搜集索引的书签都运用RID。

　　1、堆上的非搜集索引：基于RID的书签

CREATE NONCLUSTERED INDEX FK_ProductID_ModifiedDate 　　--主键不是搜集索引，没有搜集索引 ON Sales.SalesOrderDetail(ProductID, ModifiedDate) INCLUDE (OrderQty, UnitPrice, LineTotal)

　　局部数据顺序：

　　

　　留心到以上数据是无序的。

　　上面建设的非搜集索引因为运用了RID做为书签，间接指向对应止所正在的物理位置，因而效率不错。尽管RID值用于键查找很是高效，但书签中包孕的值取详细的用户数据无关。

　　2、正在搜集索引上的非搜集索引：基于搜集键的书签

　　假如默示基于搜集索引的，则表内数据可以正在表挪动。因而，应付搜集索引来说，RID其真不得接续稳定的定位一个雷同的止。因而必须用此外的办法定位止，那个办法便是运用搜集索引的索引键。
　　运用搜集索引键做为书签可以使恰当数据正在页中的止扭转时，不须要非搜集索引的书签的值停行改观，因而非搜集索引的键就可以用于去找底层表的数据，即依据书签与数据不再基于物理位置，而是基于搜集索引查找。

　　

　　以搜集索引键做为非搜集索引的书签最好要搜集索引键满足如下范例：
　　索引应当具有惟一性：每一个索引条目书签都应当使得书签可以通过搜集索引的键值惟一确真认表中的一止，假如你创立的搜集索引键值不惟一，SQL SerZZZer将会为有重复键值的每一止主动加上一个叫uniquifier的东西使得每一止惟一。那个uniquifier对客户端是通明的。应付能否可以允许搜集索引键重复，要思考以下两点：

　　生成uniquifier删多SQL SerZZZer插入收配的格外累赘，正在插入时SQL SerZZZer还须要判断插入的值正在表中能否惟一，假如不惟一生成uniquifier值再停行插入。

　　uniquifier自身对业务数据来说是没有意义的，但是那个uniquifier自身不只仅须要占用搜集索引键的空间，还同时占用非搜集索引书签的空间

　　索引键应当短：索引键所占的字节数应当短.因为那个键还会占用非搜集索引书签的空间。比如Contact表中以Last name / first name / middle name / street组竞争为索引键看上去不错，但假如表中存正在多个非搜集索引的话状况就有些微妙了。n个非搜集索引使得Last name / first name / middle name / street那些字段被存储正在n+1个位置。

　　索引键最好不要改观：也便是索引键的值最好不要改观。应付搜集索引键的批改会使得基于那个搜集索引的所有非搜集索引同样停行批改。所以应付搜集索引的一次update会组成n个非搜集索引书签的update+1个搜集索引键值自身的update。

　　下面以一个示例来协助了解书签查找:

　　如果数据库有一张表如下：

　　

　　咱们再Name列建一个非搜集索引，而后执止下面的语句：

　　

　　从执止筹划咱们可以看到，因为Age列其真不正在非搜集索引中，所以SQL SerZZZer通过“键查找”引导到搜集表获与数据，那便是书签查找。

　　书签查找的宗旨，便是为了从非搜集索引导航到根柢表获与非搜集索引中并未包孕的信息。

二、书签查找的弊病

　　书签查找要求会见索引页面之外的数据页面，会见两组页面删多了查问逻辑读收配次数。而且，假如页面不正在内存中，书签查找可能须要正在磁盘上一个随机I/O收配来从索引页面跳转到数据页面，还须要必要的CPU才华来会萃那一数据并执止必要的收配。那是因为应付大的表，索引页面和对应的数据页面但凡正在磁盘上其真不临近。

　　假如须要删多逻辑读收配大概开销较大的物理读收配使书签查找的数据检索收配开销相当大，那个开销因素是非搜集索引更符折于返回较小的数据止数的起因。跟着查问检索的止数删多，书签查找的开销将变得无奈承受。

　　为了了解书签查找跟着检索止数删多而使feu搜集索引无效，下面来看一个真例:

　　还是这张Person表,一万数据。此次，我把索引建正在Id列，Id列的惟一性是1，因为本来Id列是作主键+搜集索引的，但被我增掉了。

　　咱们来看看下面两个查问的执止筹划，

　　返回100条：

　　

　　返回300条：

　　

　　咱们看到，当要求返回300条数据的时候，SQL SerZZZer就不正在运用Id列上的非搜集索引，而是间接停行表扫描了。因为SQL SerZZZer认为执止300次书签查找还不如间接对一张1万条记录的表停行全表扫描。

　　由上面的真例可以得出结论，返回大的结果集将删多书签查找的开销，以至低于表扫描。因而正在返回较大结果集的状况下，必须思考防行书签查找的可能性。

三、书签查找的本因

　　书签查找可能是一个开销较大的收配，所以应当阐明查问筹划，正在执止筹划被选择一个要害字查找轨范的起因。可能发现可以通过正在非搜集索引键中包孕损失的止，大概做为索引页面级别上的包孕列来防行书签查找，从而防行取书签查找相关的开销。

　　从上面的真例，咱们可以提出不雅概念：假如查问的各局部(不单是选择列表)中引用的列不都包孕正在运用的非搜集索引中，就会发作书签查找收配。

　　下面引见一个能力，咱们点击某一个执止筹划的图标之后，就能正在左侧的属性信息栏里获与到相关的执止信息。譬喻，输出列表便是原执止筹划的要返回的列。

　　

四、防行书签查找的办法

　　因为书签查找的相对开销可能很是高，所以应当尽可能检验测验挣脱书签查找收配。下面给出一下方案。

　　1、运用搜集索引

　　应付搜集索引，索引的叶子页面和表的数据页面雷同。因而，当读与搜集索引键列的值时，数据引擎可以读与其余列的值而不须要任何导航。譬喻前面的区间数据查问的收配，SQL SerZZZer通过B树构造停行查找是很是快捷的。

　　把非搜集索引转换为一个搜集索引说起来很简略。但是，那个例子和大局部可能逢到的状况下，那不成能作到，因为表曾经有了一个搜集索引。那个表的搜集索引刚好是主键。必须卸载掉所有的外键约束，卸载并且重建为一个非搜集索引。那不只要思考所波及的工做，还可能重大地映响依赖于现有搜集索引的其余查问。

　　2、运用笼罩索引

　　为了了解笼罩索引是如何防行书签查找，咱们还是应付Person来执止如下两个查问：

　　

　　下面批改索引删多Name列。

　　

　　由于非搜集索引上曾经有了须要查问的Id和Name列的数据，所以不正在须要书签查找定位到根柢表。

　　3、运用索引连贯

　　假如笼罩索引变得很是宽，这么可能要思考索引连贯技术。索引连贯技术运用两个或更多索引之间的一个索引交叉来彻底笼罩一个查问。因为索引连贯技术须要会见多余一个索引，它必须正在所有索引连贯中运用的索引上执止逻辑读。因而，索引连贯须要比笼罩索引更高的逻辑读数质。但是，因为索引连贯所用的多个窄索引能够比宽的笼罩索引效劳更多的查问。所以索引连贯也可以做为防行书签查找的一种技术来思考。

　　咱们来看下面的真例：

　　

　　把稳到，上面的例子咱们创立了两个非搜集索引，一个正在 Id列，一个正在Name列。但是咱们的查问须要同时返回Id列和Name列。而那两个非搜集索引都不彻底包孕要返回列。那个时候，哈希婚配宗旨便是通过定位到索引，而不用定位到根柢表就能够与得咱们所须要的全副数据，那样索引连贯就防行了书签查找。