• sqlserver的索引创建


    随着系统数据的增多,一些查询逐渐变慢,这时候我们可以根据sqlserver的执行计划,查看sql的开销,然后根据开销创建索引。

    索引有聚集索引与非聚集索引。

    聚集索引:聚集索引在存储上是按照顺序存储的,就像字典里的汉字。

    非聚集索引:物理存储不连续,但逻辑上是连续的,因为单独维护着数据的存储位置与数据的关系。

    首先写入100000数据

    DECLARE @i INT,    
    @num int    
    SET @i=0   
    SET @num=100000    
    WHILE @i<=@num    
    BEGIN    
     IF NOT EXISTS(SELECT * FROM  dbo.meter_manage WHERE meter_id=@i)    
     INSERT INTO dbo.meter_manage    
             ( meter_id ,    
               meter_no ,    
               meter_name     
             )    
     VALUES    
             ( @i , -- meter_id - int    
               'asdasd'+CONVERT(VARCHAR(20),@i), -- meter_no - varchar(500)    
               'asdsf'++CONVERT(VARCHAR(20),@i)  -- meter_name - varchar(500)    
             );    
             SET @i=@i+1;    
    END    
      go

    非聚集索引的创建:

    create NONCLUSTERED INDEX index1 ON meter_manage(meter_no)  

    效果:

    select * from meter_manage where meter_no='asdasd2'

    创建非聚集索引之前,耗时23毫秒左右

    创建非聚集索引之后,瞬间完成

     经常使用多条件语句查询时,我们可创建复合索引。

    select * from meter_manage where meter_no='asdasd2' and meter_name='asdsf2'

    未创建非聚集索引,耗时30毫秒:

    在meter_no字段创建单索引,耗时3毫秒:

    create NONCLUSTERED INDEX index1 ON meter_manage(meter_no)  

    条件查询位置更换:

    select * from meter_manage where meter_name='asdsf2' and  meter_no='asdasd2' 

    查询速度没变,同样3毫秒。

    我们同时在另一个字段meter_name上也建立一个非聚集索引:

    create NONCLUSTERED INDEX index2 ON meter_manage(meter_name)  

    发现两个非聚集索引的时间与一个聚集索引的时间没有太大变化,查看执行计划,只命中了index1索引:

    分析:

    我们来想象一下当数据库有N个索引并且查询中分别都要用上他们的情况:
    查询优化器(用大白话说就是生成执行计划的那个东西)需要进行N次主二叉树查找[这里主二叉树的意思是最外层的索引节点],此处的查找流程大概如下:
    查出第一条column1主二叉树等于1的值,然后去第二条column2主二叉树查出foo的值并且当前行的coumn1必须等于1,最后去column主二叉树查找bar的值并且column1必须等于1和column2必须等于foo。
    如果这样的流程被查询优化器执行一遍,就算不死也半条命了,查询优化器可等不及把以上计划都执行一遍,贪婪算法(最近邻居算法)可不允许这种情况的发生,所以当遇到以下语句的时候,数据库只要用到第一个筛选列的索引(column1),就会直接去进行表扫描了。

    select count(1) from table1 where column1 = 1 and column2 = 'foo' and column3 = 'bar'

    所以与其说是数据库只支持一条查询语句只使用一个索引,倒不如说N条独立索引同时在一条语句使用的消耗比只使用一个索引还要慢。
    所以如上条的情况,最佳推荐是使用index(column1,column2,column3) 这种联合索引,此联合索引可以把b+tree结构的优势发挥得淋漓尽致:
    一条主二叉树(column=1),查询到column=1节点后基于当前节点进行二级二叉树column2=foo的查询,在二级二叉树查询到column2=foo后,去三级二叉树column3=bar查找。

    结论:两个单独索引通常数据库只能使用其中一个

    创建复合索引:

    create index idx1 on meter_manage(meter_no,meter_name) 

    瞬间完成,发现多条件下适合创建复合索引。

    条件位置改变一下

    select * from meter_manage where meter_name='asdsf2' and  meter_no='asdasd2' 

    同样瞬间完成。查看执行计划命中了idx1

    我们去掉二个条件:

    select * from meter_manage where meter_no='asdasd2'

    同样瞬间完成,也命中了索引  idx1

    我们去掉第一个条件:

    select * from meter_manage where meter_name='asdsf2'

    耗时27毫秒,与不加索引没什么区别,查看执行计划,发现虽然命中了idx1

    但是类型却是Index Scan,与之前的Index Seek不同

     区别:

    [Table Scan] 表扫描(最慢),对表记录逐行进行检查

    [Clustered Index Scan] 聚集索引扫描(较慢),按聚集索引对记录逐行进行检查

    [Index Scan] 索引扫描(普通),根据索引滤出部分数据在进行逐行检查

    [Index Seek] 索引查找(较快),根据索引定位记录所在位置再取出记录

    [Clustered Index Seek] 聚集索引查找(最快),直接根据聚集索引获取记录

    因此,字段上同时存在聚集索引与非聚集索引,这种情况下只会命中聚集索引,因为聚集索引最快,例如:主键上创建非聚集索引

    create NONCLUSTERED INDEX index3 ON meter_manage(meter_id)  

    瞬间完成,执行计划:

  • 相关阅读:
    可视化工具D3.js教程 入门 (第三章)—— 理解 Update Enter Exit
    可视化工具D3.js教程 入门 (第二章)—— 选择元素与数据绑定
    可视化工具D3.js教程 入门 (第一章)—— hello world
    可视化工具D3.js教程 入门 (V5版)
    [译]C语言实现一个简易的Hash table(3)
    [译]C语言实现一个简易的Hash table(2)
    [译]C语言实现一个简易的Hash table(1)
    C/C++中的malloc、calloc和realloc
    数据结构--单向链表
    使用Screen管理远程会话
  • 原文地址:https://www.cnblogs.com/chenyishi/p/9146097.html
Copyright © 2020-2023  润新知