数据库 索引

索引是你按什么查,我首先吧这个列按某一个顺序排好,,那数据多的时候,我就可以查的更快了

比如说 一张表  id(自增),name, telphone,addreess,这张表有3000w的数据,,我要是查姓名为 程序员 的的人的信息,你可以这样写

where name='程序员',但是你会发现很慢,因为他会一条一套的查,肯定慢啊,,对吧

如果我要是想查字典拿样,我先拍好,然后只要查到以c开头的,,那么c后面的数据我就不用查了,岂不是很快的,至于怎么把数据按照字典排列,那就是索引了

索引其实就是棵二叉树,按照树来查

唯一索引：唯一索引不允许两行具有相同的索引值
主键索引：为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的，并且不能为空
聚集索引(Clustered)：表中各行的物理顺序与键值的逻辑（索引）顺序相同，每个表只能有一个
非聚集索引(Non-clustered)：非聚集索引指定表的逻辑顺序。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于249个

优点
加快访问速度
加强行的唯一性
缺点
带索引的表在数据库中需要更多的存储空间
操纵数据的命令需要更长的处理时间，因为它们需要对索引进行更新

请按照下列标准选择建立索引的列。
该列用于频繁搜索
该列用于对数据进行排序

一、索引的概念
        索引就是加快检索表中数据的方法。数据库的索引类似于书籍的索引。在书籍中，索引允许用户不必翻阅完整个书就能迅速地找到所需要的信息。在数据库中，索引也允许数据库程序迅速地找到表中的数据，而不必扫描整个数据库。
二、索引的特点
    1.索引可以加快数据库的检索速度
    2.索引降低了数据库插入、修改、删除等维护任务的速度
    3.索引创建在表上，不能创建在视图上
    4.索引既可以直接创建，也可以间接创建
    5.可以在优化隐藏中，使用索引
    6.使用查询处理器执行SQL语句，在一个表上，一次只能使用一个索引
    7.其他
三、索引的优点
    1.创建唯一性索引，保证数据库表中每一行数据的唯一性
    2.大大加快数据的检索速度，这也是创建索引的最主要的原因
    3.加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
    4.在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。
    5.通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能。
四、索引的缺点
    1.创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加
    2.索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大
    3.当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，降低了数据的维护速度
五、索引分类
    1.直接创建索引和间接创建索引
    直接创建索引： CREATE INDEX mycolumn_index ON mytable (myclumn)
    间接创建索引：定义主键约束或者唯一性键约束，可以间接创建索引
    2.普通索引和唯一性索引
    普通索引：CREATE INDEX mycolumn_index ON mytable (myclumn)
    唯一性索引：保证在索引列中的全部数据是唯一的，对聚簇索引和非聚簇索引都可以使用
    CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)
    3.单个索引和复合索引
    单个索引：即非复合索引
    复合索引：又叫组合索引，在索引建立语句中同时包含多个字段名，最多16个字段
    CREATE INDEX name_index ON username(firstname,lastname)
    4.聚簇索引和非聚簇索引(聚集索引，群集索引)
   聚簇索引：物理索引，与基表的物理顺序相同，数据值的顺序总是按照顺序排列
    CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn) WITH
    ALLOW_DUP_ROW(允许有重复记录的聚簇索引)
   非聚簇索引：CREATE UNCLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)
六、索引的使用
   1.当字段数据更新频率较低，查询使用频率较高并且存在大量重复值是建议使用聚簇索引
    2.经常同时存取多列，且每列都含有重复值可考虑建立组合索引
    3.复合索引的前导列一定好控制好，否则无法起到索引的效果。如果查询时前导列不在查询条件中则该复合索引不会被使用。前导列一定是使用最频繁的列
    4.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案
    5.where子句中对列的任何操作结果都是在sql运行时逐列计算得到的，因此它不得不进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么就可以被sql优化器优化，使用索引，避免表搜索(例：select * from record where substring(card_no,1,4)=’5378’
&& select * from record where card_no like ’5378%’)任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边
    6.where条件中的’in’在逻辑上相当于’or’，所以语法分析器会将in ('0','1')转化为column='0' or column='1'来执行。我们期望它会根据每个or子句分别查找，再将结果相加，这样可以利用column上的索引；但实际上它却采用了"or策略 "，即先取出满足每个or子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉重复行，最后从这个临时表中计算结果。因此，实际过程没有利用 column上索引，并且完成时间还要受tempdb数据库性能的影响。in、or子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引
    7.要善于使用存储过程，它使sql变得更加灵活和高效

 

聚集索引的区别

　　聚集索引:物理存储按照索引排序

　　非聚集索引:物理存储不按照索引排序

优势与缺点

聚集索引：插入数据时速度要慢（时间花费在“物理存储的排序”上，也就是首先要找到位置然后插入）,查询数据比非聚集数据的速度快

聚集索引的区别

　　聚集索引:物理存储按照索引排序

　　非聚集索引:物理存储不按照索引排序

优势与缺点

聚集索引：插入数据时速度要慢（时间花费在“物理存储的排序”上，也就是首先要找到位置然后插入）,查询数据比非聚集数据的速度快

索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。如下图：

非聚集索引

聚集索引

一、索引块与数据块的区别

大家都知道，索引可以提高检索效率，因为它的二叉树结构以及占用空间小，所以访问速度块。让我们来算一道数学题：如果表中的一条记录在磁盘上占用1000字节的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引块的大小只有10字节。我们知道，SQL Server的最小空间分配单元是“页（Page）”，一个页在磁盘上占用8K空间，那么这一个页可以存储上述记录8条，但可以存储索引800条。现在我们要从一个有8000条记录的表中检索符合某个条件的记录，如果没有索引的话，我们可能需要遍历8000条×1000字节/8K字节=1000个页面才能够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上的指针逐一找到结果数据块，这样IO访问量要少的多。

二、索引优化技术

是不是有索引就一定检索的快呢？答案是否。有些时候用索引还不如不用索引快。比如说我们要检索上述表中的所有记录，如果不用索引，需要访问8000条×1000 字节/8K字节=1000个页面，如果使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根据索引检索结果去对应数据页面，由于是检索所有数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了1010个页面，这显然不如不用索引快。

SQL Server内部有一套完整的数据检索优化技术，在上述情况下，SQL Server的查询计划（Search Plan）会自动使用表扫描的方式检索数据而不会使用任何索引。那么SQL Server是怎么知道什么时候用索引，什么时候不用索引的呢？SQL Server除了日常维护数据信息外，还维护着数据统计信息，下图是数据库属性页面的一个截图：

 

聚簇索引与非聚簇索引的本质区别到底是什么？什么时候用聚簇索引，什么时候用非聚簇索引？

这是一个很复杂的问题，很难用三言两语说清楚。我在这里从SQL Server索引优化查询的角度简单谈谈(如果对这方面感兴趣的话，可以读一读微软出版的《Microsoft SQL Server 2000数据库编程》第3单元的数据结构引论以及第6、13、14单元)。
从图中我们可以看到，SQL Server自动维护统计信息，这些统计信息包括数据密度信息以及数据分布信息，这些信息帮助SQL Server决定如何制定查询计划以及查询是是否使用索引以及使用什么样的索引（这里就不再解释它们到底如何帮助SQL Server建立查询计划的了）。我们还是来做个实验。建立一张表：tabTest(ID, unqValue，intValue)，其中ID是整形自动编号主索引，unqValue是uniqueidentifier类型，在上面建立普通索引，intValue 是整形，不建立索引。之所以挂上一个没有索引的intValue字段，就是防止SQL Server使用索引覆盖查询优化技术，这样实验就起不到作用了。向表中录入10000条随机记录，代码如下：

CREATETABLE[dbo].[tabTest] (

[ID][int]IDENTITY (1, 1) NOTNULL ,

[unqValue][uniqueidentifier]NOTNULL ,

[intValue][int]NOTNULL

) ON[PRIMARY]

GO



ALTERTABLE[dbo].[tabTest]WITHNOCHECKADD

CONSTRAINT[PK_tabTest]PRIMARYKEYCLUSTERED

(

  [ID]

)  ON[PRIMARY]

GO



ALTERTABLE[dbo].[tabTest]ADD

CONSTRAINT[DF_tabTest_unqValue]DEFAULT (newid()) FOR[unqValue]

GO



CREATEINDEX[IX_tabTest_unqValue]ON[dbo].[tabTest]([unqValue]) ON[PRIMARY]

GO



declare@iint

declare@vint



set@i=0

while@i<10000

begin

    set@v=rand()*1000    

    insertinto tabTest ([intValue]) values (@v)

    set@i=@i+1

end

然后我们执行两个查询并查看执行计划，如图：（在查询分析器的查询菜单中可以打开查询计划，同时图上第一个查询的GUID是我从数据库中找的，大家做实验的时候可以根据自己数据库中的值来定）：

 从图中可以看出，在第一个查询中，SQL Server使用了IX_tabTest_unqValue索引，根据箭头方向，计算机先在索引范围内找，找到后，使用Bookmark Lookup将索引节点映射到数据节点上，最后给出SELECT结果。在第二个查询中，系统直接遍历表给出结果，不过它使用了聚簇索引，为什么呢？不要忘了，聚簇索引的页节点就是数据节点！这样使用聚簇索引会更快一些（不受数据删除、更新留下的存储空洞的影响，直接遍历数据是要跳过这些空洞的）。

下面，我们在SQL Server中将ID字段的聚簇索引更改为非聚簇索引，然后再执行select * from tabTest，这回我们看到的执行计划变成了：

SQL Server没有使用任何索引，而是直接执行了Table Scan，因为只有这样，检索效率才是最高的。


三、聚簇索引与非聚簇索引的本质区别

现在可以讨论聚簇索引与非聚簇索引的本质区别了。正如本文最前面的两个图所示，聚簇索引的叶节点就是数据节点，而非聚簇索引的页节点仍然是索引检点，并保留一个链接指向对应数据块。

还是通过一道数学题来看看它们的区别吧：假设有一8000条记录的表，表中每条记录在磁盘上占用1000字节，如果在一个10字节长的字段上建立非聚簇索引主键，需要二叉树节点16000个（这16000个节点中有8000个叶节点，每个页节点都指向一个数据记录），这样数据将占用8000条×1000字节 /8K字节=1000个页面；索引将占用16000个节点×10字节/8K字节=20个页面，共计1020个页面。

同样一张表，如果我们在对应字段上建立聚簇索引主键，由于聚簇索引的页节点就是数据节点，所以索引节点仅有8000个，占用10个页面，数据仍然占有1000个页面。

下面我们看看在执行插入操作时，非聚簇索引的主键为什么比聚簇索引主键要快。主键约束要求主键不能出现重复，那么SQL Server是怎么知道不出现重复的呢？唯一的方法就是检索。对于非聚簇索引，只需要检索20个页面中的16000个节点就知道是否有重复，因为所有主键键值在这16000个索引节点中都包含了。但对于聚簇索引，索引节点仅仅包含了8000个中间节点，至于会不会出现重复必须检索另外8000个页数据节点才知道，那么相当于检索10+1000=1010个页面才知道是否有重复。所以聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。

让我们再来看看数据检索的效率，如果对上述两表进行检索，在使用索引的情况下（有些时候SQL Server执行计划会选择不使用索引，不过我们这里姑且假设一定使用索引），对于聚簇索引检索，我们可能会访问10个索引页面外加1000个数据页面得到结果（实际情况要比这个好），而对于非聚簇索引，系统会从20个页面中找到符合条件的节点，再映射到1000个数据页面上（这也是最糟糕的情况），比较一下，一个访问了1010个页面而另一个访问了1020个页面，可见检索效率差异并不是很大。所以不管非聚簇索引也好还是聚簇索引也好，都适合排序，聚簇索引仅仅比非聚簇索引快一点。

结语

关于聚簇索引与非聚簇索引效率问题的实验就不做了，感兴趣的话可以自己使用查询分析器对查询计划进行分析。SQL Server是一个很复杂的系统，尤其是索引以及查询优化技术，Oracle就更复杂了。了解索引以及查询背后的事情不是什么坏事，它可以帮助我们更为深刻的了解我们的系统。

-------------------------------------

非聚簇对于更新肯定是有优势的
而它在检索的性能损失也不会太大

所以能不用聚簇当然是最好的了
但是如果使用order by的话　
聚簇的优势也应该是很明显的

-------------------------------------

   索引有两种类型：聚簇索引和非聚簇索引。

在聚簇索引中，索引树的叶级页包含实际的数据：记录的索引顺序与物理顺序相同。
在非聚簇索引中，叶级页指向表中的记录：记录的物理顺序与逻辑顺序没有必然的联系。

聚簇索引非常象目录表，目录表的顺序与实际的页码顺序是一致的。非聚簇索引则更象书的标准索引表，索引表中的顺序通常与实际的页码顺序是不一致的。一本书也许有多个索引。例如，它也许同时有主题索引和作者索引。同样，一个表可以有多个非聚簇索引。

通常情况下，你使用的是聚簇索引，但是你应该对两种类型索引的优缺点都有所理解。

每个表只能有一个聚簇索引，因为一个表中的记录只能以一种物理顺序存放。通常你要对一个表按照标识字段建立聚簇索引。但是，你也可以对其它类型的字段建立聚簇索引，如字符型，数值型和日期时间型字段。
从建立了聚簇索引的表中取出数据要比建立了非聚簇索引的表快。当你需要取出一定范围内的数据时，用聚簇索引也比用非聚簇索引好。例如，假设你用一个表来记录访问者在你网点上的活动。如果你想取出在一定时间段内的登录信息，你应该对这个表的DATETIME型字段建立聚簇索引。
对聚簇索引的主要限制是每个表只能建立一个聚簇索引。但是，一个表可以有不止一个非聚簇索引。实际上，对每个表你最多可以建立249个非聚簇索引。你也可以对一个表同时建立聚簇索引和非聚簇索引。
假如你不仅想根据日期，而且想根据用户名从你的网点活动日志中取数据。在这种情况下，同时建立一个聚簇索引和非聚簇索引是有效的。你可以对日期时间字段建立聚簇索引，对用户名字段建立非聚簇索引。如果你发现你需要更多的索引方式，你可以增加更多的非聚簇索引。
非聚簇索引需要大量的硬盘空间和内存。另外，虽然非聚簇索引可以提高从表中取数据的速度，它也会降低向表中插入和更新数据的速度。每当你改变了一个建立了非聚簇索引的表中的数据时，必须同时更新索引。因此你对一个表建立非聚簇索引时要慎重考虑。如果你预计一个表需要频繁地更新数据，那么不要对它建立太多非聚簇索引。另外，如果硬盘和内存空间有限，也应该限制使用非聚簇索引的数量。

索引属性

这两种类型的索引都有两个重要属性：
你可以用两者中任一种类型同时对多个字段建立索引（复合索引）；
两种类型的索引都可以指定为唯一索引。
你可以对多个字段建立一个复合索引，甚至是复合的聚簇索引。假如有一个表记录了你的网点访问者的姓和名字。如果你希望根据完整姓名从表中取数据，你需要建立一个同时对姓字段和名字字段进行的索引。这和分别对两个字段建立单独的索引是不同的。当你希望同时对不止一个字段进行查询时，你应该建立一个对多个字段的索引。如果你希望对各个字段进行分别查询，你应该对各字段建立独立的索引。
两种类型的索引都可以被指定为唯一索引。如果对一个字段建立了唯一索引，你将不能向这个字段输入重复的值。一个标识字段会自动成为唯一值字段，但你也可以对其它类型的字段建立唯一索引。假设你用一个表来保存你的网点的用户密码，你当然不希望两个用户有相同的密码。通过强制一个字段成为唯一值字段，你可以防止这种情况的发生。 

http://hi.baidu.com/guobeilei/blog/item/51f55afbda311e116c22eb0e.html

聚集索引基于数据行的键值在表内排序和存储这些数据行。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序存储。有关聚集索引体系结构的详细信息，请参阅聚集索引结构。

每个表几乎都对列定义聚集索引来实现下列功能：

• 可用于经常使用的查询。
• 提供高度唯一性。
  
  

  注意：

  创建 PRIMARY KEY 约束时，将在列上自动创建唯一索引。默认情况下，此索引是聚集索引，但是在创建约束时，可以指定创建非聚集索引。

• 可用于范围查询。

如果未使用 UNIQUE 属性创建聚集索引，数据库引擎将向表自动添加一个 4 字节的 uniqueifier 列。必要时，数据库引擎将向行自动添加一个 uniqueifier 值以使每个键唯一。此列和列值供内部使用，用户不能查看或访问。

查询注意事项

在创建聚集索引之前，应先了解数据是如何被访问的。考虑对具有以下特点的查询使用聚集索引：

• 使用运算符（如 BETWEEN、>、>=、< 和 <=）返回一系列值。
  
  使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行物理相邻。例如，如果某个查询在一系列销售订单号间检索记录，SalesOrderNumber 列的聚集索引可快速定位包含起始销售订单号的行，然后检索表中所有连续的行，直到检索到最后的销售订单号。
• 返回大型结果集。
• 使用 JOIN 子句；一般情况下，使用该子句的是外键列。
• 使用 ORDER BY 或 GROUP BY 子句。
  
  在 ORDER BY 或 GROUP BY 子句中指定的列的索引，可以使数据库引擎不必对数据进行排序，因为这些行已经排序。这样可以提高查询性能。

列注意事项

一般情况下，定义聚集索引键时使用的列越少越好。考虑具有下列一个或多个属性的列：

• 唯一或包含许多不重复的值
  
  例如，雇员 ID 唯一地标识雇员。EmployeeID 列的聚集索引或 PRIMARY KEY 约束将改善基于雇员 ID 号搜索雇员信息的查询的性能。另外，可对 LastName、FirstName、MiddleName 列创建聚集索引，因为经常以这种方式分组和查询雇员记录，而且这些列的组合还可提供高区分度。
• 按顺序被访问
  
  例如，产品 ID 唯一地标识 AdventureWorks 数据库的 Production.Product 表中的产品。在其中指定顺序搜索的查询（如 WHERE ProductID BETWEEN 980 and 999）将从 ProductID 的聚集索引受益。这是因为行将按该键列的排序顺序存储。
• 由于保证了列在表中是唯一的，所以定义为 IDENTITY。
• 经常用于对表中检索到的数据进行排序。
  
  按该列对表进行聚集（即物理排序）是一个好方法，它可以在每次查询该列时节省排序操作的成本。

聚集索引不适用于具有下列属性的列：

• 频繁更改的列
  
  这将导致整行移动，因为数据库引擎必须按物理顺序保留行中的数据值。这一点要特别注意，因为在大容量事务处理系统中数据通常是可变的。
• 宽键
  
  宽键是若干列或若干大型列的组合。所有非聚集索引将聚集索引中的键值用作查找键。为同一表定义的任何非聚集索引都将增大许多，这是因为非聚集索引项包含聚集键，同时也包含为此非聚集索引定义的键列。

索引选项

创建聚集索引时，可指定若干索引选项。因为聚集索引通常都很大，所以应特别注意下列选项：

• SORT_IN_TEMPDB
• DROP_EXISTING
• FILLFACTOR
• ONLINE

但是oracle 还有一个索引就是逆序索引 ,一般情况下建表的时候,都会设定一个自增的ID,但是我如果要一次性插入10w条数据是不是很慢的,每个iD都是差距为1,这个id必须等到上个id插入数据并查处这个Id是多少,然后加1 ,才能入库,这是不是就是串行了,一个步骤一个步骤执行的,我们改为并行的,就行当于是多线程的效果,在Oracle里面的就是逆序索引,你新建逆序索引的时候,它会把这列的bit反过来排列,这样查找的时候,条件也是逆的,插入数据库的时候,查找ID还是挺快的,比一般的索引还是快了

还有一种索引哈希索引,就是一个值对应一个地址类型的

（一）问题提出

1，当表中一个字段过长时，建立索引就不适合的了，建立索引的一个原则就是索引不能太宽。

2，对于varchar(max)、nvarchar(max) 和 varbinary(max) 大值数据类型根本就不能建立索引。

3，对于这个情况怎么办呢？

4，哈希索引就派上了用场。

（二）示例代码

 

?

-建立测试表

CREATE TABLE hash_index

  (

     id   INT IDENTITY(1, 1) PRIMARY KEY,

     name VARCHAR(max)

  )

   

go

--插入10000测试数据

WITH cte

     AS (SELECT NUMBER + 1 AS NUMBER

         FROM   master..spt_values a

         WHERE  a.TYPE = 'P'

                AND NUMBER < 100)

INSERT INTO hash_index

            (name)

SELECT Cast(Newid() AS VARCHAR(50)) + Cast(Newid() AS VARCHAR(50)) + Cast(

              Newid() AS VARCHAR(50)) + Cast(Newid() AS VARCHAR(50)) + Cast(

              Newid() AS VARCHAR(50)) + Cast(Newid() AS VARCHAR(50)) + Cast(

              Newid() AS VARCHAR(50))

FROM   cte a

       CROSS JOIN cte b

   

go

--增加计算列

ALTER TABLE hash_index

  ADD cs_name AS Checksum(name);

   

go

--增加索引

CREATE INDEX idx_name

  ON hash_index(cs_name)

 

 

（三）查询示例

?

--查询一表扫描

SELECT *

FROM   hash_index

WHERE  name =

'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5'

--查询二哈希索引

SELECT *

FROM   hash_index

WHERE  name =

'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5'

AND cs_name = Checksum(

'C3AA9897-9303-48C9-B2C2-758C0FFE0BB1ABB3F6FB-BC2C-45DF-B40A-E3DA413AD91E1A598E90-31FE-4F54-B468-0D085A191DA37A35782D-B048-4A6B-89CA-00A15FC1467E0235D0F1-A9EA-4908-9531-3D787C7E7AAA2E6DB162-1099-4B3B-BF93-261B87660B1359768A42-F9F7-4107-9D57-BCB91EEF3CD5'

)

 （四）对比性能消耗
表 'hash_index'。扫描计数 1，逻辑读取 340 次，物理读取 4 次，预读 133 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'hash_index'。扫描计数 1，逻辑读取 5 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

但是哈希索引 只能对于是否等于的关系,

 所以说模糊查询和范围查询都是适合

EXEC sp_helpindex "Hotel.dbo.cdsgus " 查找Hotel数据库里cdsgus表的索引