• SQL Server 索引基础知识(2)聚集索引,非聚集索引(转)


    聚集索引

      一种索引,该索引中键值的逻辑顺序决定了表中相应行的物理顺序。
      聚集索引确定表中数据的物理顺序。聚集索引类似于电话簿,按姓氏排列数据。由于聚集索引规定数据在表中的物理存储顺序,因此一个表只能包含一个聚集索引。但该索引可以包含多个列(组合索引),就像电话簿按姓氏和名字进行组织一样。
        
         聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后,便可以确保包含后续索引值的行在物理相邻。例如,如果应用程序执行的一个查询经常检索某一日期范围内的记录,则使用聚集索引可以迅速找到包含开始日期的行,然后检索表中所有相邻的行,直到到达结束日期。这样有助于提高此类查询的性能。同样,如果对从表中检索的数据进行排序时经常要用到某一列,则可以将该表在该列上聚集(物理排序),避免每次查询该列时都进行排序,从而节省成本。
        
         当索引值唯一时,使用聚集索引查找特定的行也很有效率。例如,使用唯一雇员 ID 列 emp_id 查找特定雇员的最快速的方法,是在 emp_id 列上创建聚集索引或 PRIMARY KEY 约束。
      适用于聚集索引的情况包括:
      1、含有大量非重复值的列。
      2、使用BETWEEN,>,>=,<或<=返回一个范围值的列
      3、被连续访问的列
      4、返回大型结果集的查询
      5、经常被使用连接或GROUP BY子句的查询访问的列
     
    聚集索引,非聚集索引在B+树结构的基础上,区别和值类型和引用类型很象
     
    下面转了一个文章具体学习

    由于需要给同事培训数据库的索引知识,就收集整理了这个系列的博客。发表在这里,也是对索引知识的一个总结回顾吧。通过总结,我发现自己以前很多很模糊的概念都清晰了很多。

    不论是 聚集索引,还是非聚集索引,都是用B+树来实现的。我们在了解这两种索引之前,需要先了解B+树。如果你对B树不了解的话,建议参看以下几篇文章:

    BTree,B-Tree,B+Tree,B*Tree都是什么
    http://blog.csdn.net/manesking/archive/2007/02/09/1505979.aspx

    B+ 树的结构图:

    B+ 树的特点:

    • 所有关键字都出现在叶子结点的链表中(稠密索引),且链表中的关键字恰好是有序的;
    • 不可能在非叶子结点命中;
    • 非叶子结点相当于是叶子结点的索引(稀疏索引),叶子结点相当于是存储(关键字)数据的数据层;

    B+ 树中增加一个数据,或者删除一个数据,需要分多种情况处理,比较复杂,这里就不详述这个内容了。 

    聚集索引(Clustered Index)

    • 聚集索引的叶节点就是实际的数据页
    • 在数据页中数据按照索引顺序存储
    • 行的物理位置和行在索引中的位置是相同的
    • 每个表只能有一个聚集索引
    • 聚集索引的平均大小大约为表大小的5%左右

    下面是两副简单描述聚集索引的示意图: 

    在聚集索引中执行下面语句的的过程:

    select * from table where firstName = 'Ota'

     在聚集索引中搜索

    一个比较抽象点的聚集索引图示:

    聚集索引单个分区中的结构

     

    非聚集索引 (Unclustered Index)  

    • 非聚集索引的页,不是数据,而是指向数据页的页。
    • 若未指定索引类型,则默认为非聚集索引
    • 叶节点页的次序和表的物理存储次序不同
    • 每个表最多可以有249个非聚集索引
    • 在非聚集索引创建之前创建聚集索引(否则会引发索引重建)

    在非聚集索引中执行下面语句的的过程:

    select * from employee where lname = 'Green'

    Selecting rows using a nonclustered index

    一个比较抽象点的非聚集索引图示:

    非聚集索引的级别

    什么是 Bookmark Lookup

    虽然SQL 2005 中已经不在提  Bookmark Lookup 了(换汤不换药),但是我们的很多搜索都是用的这样的搜索过程,如下:
    先在非聚集中找,然后再在聚集索引中找。

    Bookmark Lookup 

    http://www.sqlskills.com/ 提供的一个例子中,就给我们演示了 Bookmark Lookup  比 Table Scan 慢的情况,例子的脚本如下:

    USE CREDIT
    go
    
    -- These samples use the Credit database. You can download and restore the
    -- credit database from here:
    -- http://www.sqlskills.com/resources/conferences/CreditBackup80.zip
    
    -- NOTE: This is a SQL Server 2000 backup and MANY examples will work on 
    -- SQL Server 2000 in addition to SQL Server 2005.
    -------------------------------------------------------------------------------
    -- (1) Create two tables which are copies of charge:
    -------------------------------------------------------------------------------
    
    -- Create the HEAP
    SELECT * INTO ChargeHeap FROM Charge
    go
    
    -- Create the CL Table
    SELECT * INTO ChargeCL FROM Charge
    go
    
    CREATE CLUSTERED INDEX ChargeCL_CLInd ON ChargeCL (member_no, charge_no)
    go
    
    -------------------------------------------------------------------------------
    -- (2) Add the same non-clustered indexes to BOTH of these tables:
    -------------------------------------------------------------------------------
    
    -- Create the NC index on the HEAP
    CREATE INDEX ChargeHeap_NCInd ON ChargeHeap (Charge_no)
    go
    
    -- Create the NC index on the CL Table
    CREATE INDEX ChargeCL_NCInd ON ChargeCL (Charge_no)
    go
    
    -------------------------------------------------------------------------------
    -- (3) Begin to query these tables and see what kind of access and I/O returns
    -------------------------------------------------------------------------------
    
    -- Get ready for a bit of analysis:
    SET STATISTICS IO ON
    -- Turn Graphical Showplan ON (Ctrl+K)
    
    -- First, a point query (also, see how a bookmark lookup looks in 2005)
    SELECT * FROM ChargeHeap WHERE Charge_no = 12345
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no = 12345
    go
    
    -- What if our query is less selective?
    -- 1000 is .0625% of our data... (1,600,000 million rows)
    SELECT * FROM ChargeHeap WHERE Charge_no < 1000
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no < 1000
    go
    
    -- What if our query is less selective?
    -- 16000 is 1% of our data... (1,600,000 million rows)
    SELECT * FROM ChargeHeap WHERE Charge_no < 16000
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no < 16000
    go
    
    -------------------------------------------------------------------------------
    -- (4) What's the EXACT percentage where the bookmark lookup isn't worth it?
    -------------------------------------------------------------------------------
    
    -- What happens here: Table Scan or Bookmark lookup?
    SELECT * FROM ChargeHeap WHERE Charge_no < 4000
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no < 4000
    go
    
    -- What happens here: Table Scan or Bookmark lookup?
    SELECT * FROM ChargeHeap WHERE Charge_no < 3000
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no < 3000
    go
    
    -- And - you can narrow it down by trying the middle ground:
    -- What happens here: Table Scan or Bookmark lookup?
    SELECT * FROM ChargeHeap WHERE Charge_no < 3500
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no < 3500
    go
    
    -- And again:
    SELECT * FROM ChargeHeap WHERE Charge_no < 3250
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no < 3250
    go
    
    -- And again:
    SELECT * FROM ChargeHeap WHERE Charge_no < 3375
    go
    
    SELECT * FROM ChargeCL WHERE Charge_no < 3375
    go
    
    -- Don't worry, I won't make you go through it all :)
    
    
    
    -- For the Heap Table (in THIS case), the cutoff is: 0.21%
    SELECT * FROM ChargeHeap  WHERE Charge_no < 3383
    go
    SELECT * FROM ChargeHeap WHERE Charge_no < 3384
    go
    
    
    -- For the Clustered Table (in THIS case), the cut-off is: 0.21%
    SELECT * FROM ChargeCL WHERE Charge_no < 3438
    
    SELECT * FROM ChargeCL WHERE Charge_no < 3439
    go

    这个例子也就是 吴家震 在Teched 2007 上的那个演示例子。

    小结:

    这篇博客只是简单的用几个图表来介绍索引的实现方法:B+数, 聚集索引,非聚集索引,Bookmark Lookup 的信息而已。

    参考资料:

    表组织和索引组织
    http://technet.microsoft.com/zh-cn/library/ms189051.aspx
    http://technet.microsoft.com/en-us/library/ms189051.aspx

    How Indexes Work
    http://manuals.sybase.com/onlinebooks/group-asarc/asg1200e/aseperf/@Generic__BookTextView/3358

    Bookmark Lookup
    http://blogs.msdn.com/craigfr/archive/2006/06/30/652639.aspx 

    Logical and Physical Operators Reference
    http://msdn2.microsoft.com/en-us/library/ms191158.aspx

  • 相关阅读:
    ASP.NET Core 中文文档 第四章 MVC(4.4)依赖注入和控制器
    ASP.NET Core 中文文档 第四章 MVC(4.3)过滤器
    ASP.NET Core 中文文档 第四章 MVC(4.1)Controllers, Actions 和 Action Results
    ASP.NET Core 中文文档 第四章 MVC(3.9)视图组件
    ASP.NET Core 中文文档 第四章 MVC(3.8)视图中的依赖注入
    ASP.NET Core 中文文档 第四章 MVC(3.7 )局部视图(partial)
    magento 导入语言包
    php 生成二维码(qrcode)
    在windows下的CLI模式下如何运行php文件
    ftp命令
  • 原文地址:https://www.cnblogs.com/cuihongyu3503319/p/1703981.html
Copyright © 2020-2023  润新知