03.索引-聚集索引(1)

创建聚集索引并重新组织

CREATE UNIQUE CLUSTERED INDEX CIX_Employee001_Id ON Employee001(Id);

ALTER INDEX CIX_Employee001_Id ON Employee001 REORGANIZE;

索引情况

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)

只有一个聚集索引,索引深度为3(两级聚集索引页+一级数据页),数据页数量为1615

重新查询页信息

TRUNCATE TABLE DBCCIndResult

INSERT INTO DBCCIndResult EXEC(‘DBCC IND(IndexDB,Employee001,-1)‘)

与02.索引-堆表中相比 多了一些PageType=2的页(索引页)

并且 数据页的数量变少了(1615个,不一定变少,只是可能存数据页数量不一样的情况)

同事页编号也改变了(由于需要生成聚集索引,数据页也会被重新组织,按照索引键列排序)

根据查询出的索引非叶子节点的信息,索引页有两种IndexLevel

IndexLevel=2 是根节点 IndexLevel是中间节点

IndexLevel=0肯定是数据页节点

从根节点的索引页开始看

DBCC TRACEON(3604)

DBCC PAGE (IndexDB, 1, 2162, 3);

共有16行数据,指向16个中间索引页(PageType=2,IndexLevel=1),

选择一个中间索引页查看

由于是最后一层索引页(由于数据量只有10W,因此只建立了2 Level的索引),因此数据行指向 数据页

选择一个数据页查看

DBCC TRACEON(3604)

DBCC PAGE (IndexDB, 1, 2260, 3) WITH TABLERESULTS;

将数据插入到表中,方便查询

--查看分页情况

SELECT * FROM DBCCIndResult

--查看页的详细数据

DBCC TRACEON(3604)

TRUNCATE TABLE DBCCPageResult

--选中一页 例如 145页

INSERT INTO DBCCPageResult EXEC (‘DBCC PAGE (IndexDB, 1, 2260, 3) WITH TABLERESULTS‘)

SELECT * FROM DBCCPageResult

WHERE Field IN(‘Id‘)

可以看到Id列(聚集索引列)是按照排序排好的

查询数据,打开IO和执行计划

SET STATISTICS IO ON

SELECT Name From Employee001

WHERE Id= ‘43107053D74E484EB02B5B395178F682‘

与02.索引-堆表中(没有任何索引)相同的查询对比

执行计划为 Clustered Index Seek

只有三次逻辑读取(根据树的查找方式可以推断,三次读取分别为根索引页,一个IndexLevel=1的索引页,一个数据页)

可以进一步证明,使用下面的语句查看查询过程中使用了哪些资源:

USE [IndexDB]

GO

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ

GO

BEGIN TRAN

SET STATISTICS IO ON

SELECT Name From Employee001

WHERE Id= ‘43107053D74E484EB02B5B395178F682‘

SET STATISTICS IO OFF

USE [IndexDB] --要查询申请锁的数据库

GO

SELECT

[request_session_id],

c.[program_name],

DB_NAME(c.[dbid]) AS dbname,

[resource_type],

[request_status],

[request_mode],

[resource_description],OBJECT_NAME(p.[object_id]) AS objectname,

p.[index_id]

FROM sys.[dm_tran_locks] AS a LEFT JOIN sys.[partitions] AS p

ON a.[resource_associated_entity_id]=p.[hobt_id]

LEFT JOIN sys.[sysprocesses] AS c ON a.[request_session_id]=c.[spid]

WHERE c.[dbid]=DB_ID(‘IndexDB‘) AND a.[request_session_id]=@@SPID

ORDER BY [request_session_id],[resource_type]

COMMIT TRAN

时间: 2024-11-10 00:20:13

03.索引-聚集索引(1)的相关文章

SQL Server索引 - 聚集索引、非聚集索引、非聚集唯一索引 <第八篇>

聚集索引.非聚集索引.非聚集唯一索引 我们都知道建立适当的索引能够提高查询速度,优化查询.先说明一下,无论是聚集索引还是非聚集索引都是B树结构. 聚集索引默认与主键相匹配,在设置主键时,SQL Server会默认在主键列创建聚集索引.但是可以手动更改为在任意一个列创建聚集索引,然后在另一个字段或多个字段上定义主键.这时主键将会被作为一个唯一的非聚集索引(唯一索引)被创建.通过指定NONCLUSTERED关键字就可以做到. CREATE TABLE MyTableKeyExample { Colu

MySQL的btree索引和hash索引&聚集索引

1,BTREE是多叉树,多路径搜索树.有N棵子树的节点它包含N-1个关键字,例如,有3个子树的非叶子节点,那么就有2个关键字,每个关键字不保存数据,只用来存储索引(在索引存储数据时,将索引指向关键字的值也存储进来.最终实现key = &get; value结构).所有的数据最终都要落在叶子节点,所有的叶子节点包括关键字信息以及指向这些关键字的指针,而且叶子节点是根据关键字大小.顺序链接的.所有的叶子节点都必须有个链表指针把数据串起来.所以,所有非叶子节点可以看成索引部分,包括子树中最大值或最小值

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

聚集索引基于数据行的键值在表内排序和存储这些数据行, 每个表只能有一个聚集索引, 因为数据行本身只能按一个顺序存储. 有关聚集索引体系结构的详细信息, 请参阅 聚集索引结构. 每个表几乎都对列定义聚集索引来实现下列功能: 可用于经常使用的查询. 提供高度唯一性. 创建 PRIMARY KEY 约束时, 将在列上自动创建唯一索引. 默认情况下, 此索引是聚集索引, 但是在创建约束时,可以指定创建非聚集索引. 可用于范围查询. 如果未使用 UNIQUE 属性创建聚集索引, 数据库引擎将向表自动添加一

04.索引-聚集索引(2) 堆表、聚集表、聚集索引结构

堆表中 1.没有聚集索引页 2.数据页中的数据都是无序的 聚集表中 1.数据页都是有序的,按照索引键列排序 2.索引页指向数据页,数据页本身也是聚集索引的一部分 3.数据页的IndexLevel为0,索引页依次为1 2 3 ...,最大的IndexLevel的索引页只有一个,即根

主键,唯一索引 聚集索引的关系

为列创建索引实际上就是为列进行排序,以方便查询.建立一个列的索引,就相当与建立一个列的排序. 主键是唯一的,所以创建了一个主键的同时,也就这个字段创建了一个唯一的索引, 唯一索引实际上就是要求指定的列中所有的数据必须不同. 主键一唯一索引的区别: 1 一个表的主键只能有一个,而唯一索引可以建多个.         2 主键可以作为其它表的外键.         3 主键不可为null,唯一索引可以为null. 聚集索引:将表内的数据按照一定的规则进行排列的目录.正因为如此,一个表中的聚焦索引只有

SQL Server 索引 聚集索引、非聚集索引、堆

1.存储结构

SqlServer 聚集索引真的是最好了吗?

-- 先模拟环境,后面说明: USE [Temp] GO -- DROP TABLE [TestTab] TRUNCATE TABLE [TestTab] CREATE TABLE [dbo].[TestTab]( [UserAcount] [varchar](50) NOT NULL, [UserName] [varchar](50) NOT NULL, [crdatetime] [datetime] NOT NULL, [value] [numeric](18, 4) NULL, [Info

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

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

聚集索引

转自:mysql索引之聚集索引 聚集索引不是一种单独的索引类型,而是一种存储数据方式.其具体细节依赖于实现方式,但是InnoDB的聚集索引实际上在同样的结构中保存了B-Tree索引和数据行. 当表有聚集索引的时候,它的数据行实际保存在索引的叶子页中.术语“聚集”指实际的数据行和相关的键值都保存在一起.每个表只能有一个聚集索引,因为不能一次把行保存在两个地方.(但是,覆盖索引可以模拟多个聚集索引) 当前,SolidDB和InnoDB是唯一支持聚集索引的存储引擎.InnoDB按照主键进行聚集,如果没