07.索引-非聚集索引(3)-Key Lookup &RID Lookup

如果存在聚集索引并且查找的列不在 非聚集索引的键列中

而在没有聚集索引的表中 使用RID Lookup

书签查找可能因为开销过大导致一些查询直接进行表扫描

聚集索引所有数据都在索引中(数据页也是索引的一部分),因此可以直接通过聚集索引找到所有的列

定位到索引,也就意味着数据找到了

但是非聚集索引定位到索引后,需要在根据索引记录的RID或者Key 查找数据行,势必会导致一次数据页的I/O

数据行过多,形成的数据页IO也会非常大

当数据过大,IO反而可能超过直接进行页扫描的开销,因此系统会选择进行页扫描

因此书签查找是不可预知的,需要尽量避免

时间: 2024-10-22 04:34:32

07.索引-非聚集索引(3)-Key Lookup &RID Lookup的相关文章

Mysql 索引实现原理. 聚集索引, 非聚集索引

Mysql索引实现: B-tree,B是balance,一般用于数据库的索引.使用B-tree结构可以显著减少定位记录时所经历的中间过程,从而加快存取速度.而B+tree是B-tree的一个变种,MySQL就普遍使用B+tree实现其索引结构. 一般来说,索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储的磁盘上.这样的话,索引查找过程中就要产生磁盘I/O消耗,相对于内存存取,I/O存取的消耗要高几个数量级,所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘

SQL Server索引 - 非聚集索引 <第七篇>

一.非聚集索引维护 非聚集索引的行定位器值保持相同的聚集索引值,即使该聚集索引列物理上重新定位后,也是如此. 为了优化这个维护开销,SQL Server添加一个指向旧数据页的指针,以在页面分割之后指向新的数据页面,而不是更新所有相关非聚集索引的行定位器.这样,虽然降低了非聚集索引的维护开销,但是增加了从非聚集索引行到数据行的导航开销,因为添加了一个旧数据页面和信数据页面之间的连接.因此,将聚集索引作为行定位器降低了非聚集索引相关的开销. 二.定义书签查找 当一个查询请求不是优化器选择的非聚集索引

05.索引-非聚集索引(1)-聚集表

建立非聚集索引 CREATE NONCLUSTERED INDEX NCIX_Employee001_Department_Organization ON Employee001(Department,Organization); ALTER INDEX NCIX_Employee001_Department_Organization ON Employee001 REORGANIZE 索引情况 SELECT database_id, index_id, index_type_desc, ind

08.索引-非聚集索引(4)-联合索引、覆盖索引

避免书签查找 可以将查询需要的列加入非聚集索引中 联合索引会导致所有的非聚集索引页中都会冗余一份列的数据,尤其是当这些列不作为条件,只作为返回值时候,是一种浪费 因此可以 选择将查询结果需要的列加入覆盖索引 这时候 覆盖的列 只会存在于叶节点中,定位到索引后,直接从页节点返回数据,避免再根据RID 或者Key 读取数据页,可以减少一次IO

索引 - 非聚集索引设计指南-转载

非聚集索引包含索引键值和指向表数据存储位置的行定位器. 有关非聚集索引体系结构的详细信息, 请参阅 非聚集索引结构. 可以对表或索引视图创建多个非聚集索引. 通常, 设计非聚集索引是为改善经常使用的没有建立聚集索引的查询的性能. 与使用书中索引的方式相似, 查询优化器在搜索数据值时, 先搜索非聚集索引以找到数据值在表中的位置, 然后直接从该位置检索数据. 这使非聚集索引成为完全匹配查询的最佳选择, 因为索引包含说明查询所搜索的数据值在表中的精确位置的项. 例如, 为了从 Person.Perso

06.索引-非聚集索引(2)-堆表

删除聚集索引 DROP INDEX CIX_Employee001_Id ON Employee001 索引情况 SELECT database_id, index_id, index_type_desc, index_depth, index_level, page_count FROM sys.dm_db_index_physical_stats(DB_ID('IndexDB'),OBJECT_ID('Employee001'),null,null,null) TRUNCATE TABLE

索引深入浅出:非聚集索引的B树结构在聚集表

一个表只能有一个聚集索引,数据行以此聚集索引的顺序进行存储,一个表却能有多个非聚集索引.我们已经讨论了聚集索引的结构,这篇我们会看下非聚集索引结构. 非聚集索引的逻辑呈现 简单来说,非聚集索引是表的子集.当我们定义了一个非聚集索引时,SQL Server把整套非聚集索引键存在不同的页里.我们来看下一个包含BusinessEntityID(PK),PersonType,FirstName,LastName这4列的表,这个表上有一个非聚集索引定义.主体表按BusinessEntityID列(聚集索引

SQLSERVER聚集索引与非聚集索引的再次研究(上)

原文:SQLSERVER聚集索引与非聚集索引的再次研究(上) SQLSERVER聚集索引与非聚集索引的再次研究(上) 上篇主要说聚集索引 下篇的地址:SQLSERVER聚集索引与非聚集索引的再次研究(下) 由于本人还是SQLSERVER菜鸟一枚,加上一些实验的逻辑严谨性, 单写<SQLSERVER聚集索引与非聚集索引的再次研究(上)>就用了12个小时,两篇文章加起来最起码写了20个小时, 本人非常非常用心的努力完成这两篇文章,希望各位看官给点意见o(∩_∩)o 为了搞清楚索引内部工作原理和结构

表上999个非聚集索引——你怎么看?

对于数据获取,如果查询优化器在执行计划里选择了索引,那么SQL Server里的每个索引可以提高你的查询性能.但在另一方面,每个索引也会伤及你的性能,因为在INSERT,UPDATE和DELETE期间,每个索引需要被维护.因此对于你的工作量,尽可能创建少的索引非常重要——不然在写操作期间,你会有巨大的性能问题. 当你在表上定义了最大999个索引,SQL Server会如何反应?我从未在表上创建多大999个索引,因此详细验证下这个行为,并讨论下它引入的所有副作用,会是个很好的锻炼. 我们来创建一个