mysql索引原理以及优化

一、常见查找算法:

  1.顺序查找:

  • 最基础的查找方法,对比每一个元素进行查找。在数据量很大的时候效率相当的慢。
  • 数据结构:有序或者无需的队列
  • 时间复杂度:O(n)

  2.二分查找:

  • 二分查找首先要求数组有序
  • 每次查找从中间开始查找,比较查找对象和中间值,如果比中间值小,则去头到中间值的范围继续二分查找。如果比中间值大,则去中间值以后的数组进行二分查找。
  • 如果某一步骤数组为空,则表示没有此对象
  • 数据结构:有序数组
  • 时间复杂度:O(logN)

  3.二叉树排序:

    二叉排序树的特点是:

      a.若它的左子树不空,则左子树上所有结点的值均小于它的根结点的值;

      b.若它的右子树不空,则右子树上所有结点的值均大于它的根结点的值;

      c.它的左、右子树也分别为二叉排序树。

    搜索原理:

      a.若b是空树,则搜索失败,否则:

      b.若x等于b的根节点的数据域之值,则查找成功;否则:

      c.若x小于b的根节点的数据域之值,则搜索左子树;否则:

      d.查找右子树。

    数据结构:二叉排序树 
    时间复杂度: O(log2N)

  4.哈希散列法(哈希表)

    原理:先根据key值和哈希函数创建一个哈希表(散列表),然后根据键值,通过散列函数,定位数据元素位置。

扫描二维码关注公众号,回复: 5290443 查看本文章

    数据结构:哈希表 
    时间复杂度:几乎是O(1),取决于产生冲突的多少。

  5.分块查找

    分块查找又称索引顺序查找,它是顺序查找的一种改进方法。其算法思想是将n个数据元素”按块有序”划分为m块(m ≤ n)。每一块中的结点不必有序,但块与块之间必须”按块有序”;即第1块中任一元素的关键字都必须小于第2块中任一元素的关键字;而第2块中任一元素又都必须小于第3块中的任一元素,依次类推。 

    算法流程:

      先选取各块中的最大关键字构成一个索引表;

      查找分两个部分:先对索引表进行二分查找或顺序查找,以确定待查记录在哪一块中;然后,在已确定的块中用顺序法进行查找。

    这种搜索算法每一次比较都使搜索范围缩小一半。它们的查询速度就有了很大的提升,复杂度为。如果稍微分析一下会发现,每种查找算法都只能应用于特定的数据结构之上,例如二分查找要求被检索数据有序,而二叉树查找只能应用于二叉查找树上,但是数据本身的组织结构不可能完全满足各种数据结构(例如,理论上不可能同时将两列都按顺序进行组织),所以,在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法。这种数据结构,就是索引

二、平衡多路搜索树B树(B-tree)

三、索引数据结构设相关的计算机原理

  1. 计算机的主存(RAM)和外部存储(硬盘,CD,SSD)

    a.主存的读取速度快,相对于主存,外部磁盘的数据读取速率要比主从慢好几个数量级

    b.计算机主存一般比较小,实际数据库中数据都是存储到外部存储器

  2.索引与主存和外部存储的关系

    a.一般来说,索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储的磁盘上

    b.索引查找过程中就要产生磁盘I/O消耗,相对于内存存取,I/O存取的消耗要高几个数量级,所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。

    c.索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数

  3.主存存储原理:

    目前计算机使用的主存基本都是随机读写存储器(RAM),现代RAM的结构和存取原理比较复杂,这里本文抛却具体差别,抽象出一个十分简单的存取模型来说明RAM的工作原理。 

    

    1.从抽象角度看,主存是一系列的存储单元组成的矩阵,每个存储单元存储固定大小的数据。

    2.每个存储单元有唯一的地址,现代主存的编址规则比较复杂,这里将其简化成一个二维地址。

    3.通过一个行地址和一个列地址可以唯一定位到一个存储单元。

    主存的存取过程:

      a.当系统需要读取主存时,则将地址信号放到地址总线上传给主存,主存读到地址信号后,解析信号并定位到指定存储单元,然后将此存储单元数据放到数据总线上,供其它部件读取

      b.写主存的过程类似,系统将要写入单元地址和数据分别放在地址总线和数据总线上,主存读取两个总线的内容,做相应的写操作。

      c.主存存取的时间仅与存取次数呈线性关系,因为不存在机械操作,两次存取的数据的“距离”不会对时间有任何影响

      d.例如,先取A0再取A1和先取A0再取D3的时间消耗是一样的。

  4.磁盘存储原理

    1.索引一般以文件形式存储在磁盘上,索引检索需要磁盘I/O操作。

    2.与主存不同,磁盘I/O存在机械运动耗费,因此磁盘I/O的时间消耗是巨大的。

    3.磁盘读取数据靠的是机械运动,当需要从磁盘读取数据时,系统会将数据逻辑地址传给磁盘,磁盘的控制电路按照寻址逻辑将逻辑地址翻译成物理地址,即确定要读的数据在哪个磁道,哪个扇区。

    4.为了读取这个扇区的数据,需要将磁头放到这个扇区上方,为了实现这一点,磁头需要移动对准相应磁道,这个过程叫做寻道,所耗费时间叫做寻道时间。

    5.然后磁盘旋转将目标扇区旋转到磁头下,这个过程耗费的时间叫做旋转时间。

    6.最后便是对读取数据的传输

    7.每次读取数据花费的时间可以分为寻道时间、旋转延迟、传输时间三个部分。

    (ps.各个时间的花费:)

      • 寻道时间是磁臂移动到指定磁道所需要的时间,主流磁盘一般在5ms以下。
      • 旋转延迟就是我们经常听说的磁盘转速,比如一个磁盘7200转,表示每分钟能转7200次,也就是说1秒钟能转120次,旋转延迟就是1/120/2 = 4.17ms。
      • 传输时间指的是从磁盘读出或将数据写入磁盘的时间,一般在零点几毫秒,相对于前两个时间可以忽略不计。

     I/O操作问题:

      a. 访问一次磁盘的时间,即一次磁盘IO的时间约等于5+4.17 = 9ms左右.

      b.一台500 -MIPS的机器每秒可以执行5亿条指令.

      c.因为指令依靠的是电的性质,换句话说执行一次IO的时间可以执行40万条指令.

      d.数据库动辄十万百万乃至千万级数据,每次9毫秒的时间,显然是个灾难。

  5、磁盘预读

    因此为了提高效率,要尽量减少磁盘I/O,为了达到这个目的,磁盘往往不是严格按需读取,而是每次都会预读。

    即使只需要一个字节,磁盘也会从这个位置开始,顺序向后读取一定长度的数据放入内存。

    这样做的理论依据是计算机科学中著名的局部性原理:当一个数据被用到时,其附近的数据也通常会马上被使用。

    预读的长度一般为页(page)的整倍数。

    页是计算机管理存储器的逻辑块,硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块

    每个存储块称为一页(在许多操作系统中,页得大小通常为4k),主存和磁盘以页为单位交换数据。

    当程序要读取的数据不在主存中时,会触发一个缺页异常,此时系统会向磁盘发出读盘信号

    磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中,然后异常返回,程序继续运行。

  6.数据库索引所采用的数据结构B-/+Tree及其性能分析

    6.1、B-tree性能分析

      a.数据库索引是存储到磁盘的而我们又一般以使用磁盘I/O次数来评价索引结构的优劣

      b.根据B-Tree的定义,可知检索一次最多需要访问h-1个节点(根节点常驻内存)

      c.数据库系统的设计者巧妙利用了磁盘预读原理,将一个节点的大小设为等于一个页,这样每个节点只需要一次I/O就可以完全载入

      d.为了达到这个目的,在实际实现B-Tree还需要使用如下技巧:每次新建节点时,直接申请一个页的空间,这样就保证一个节点物理上也存储在一个页里,加之计算机存储分配都是按页对齐的,就实现了一个node只需一次I/O

      e.B-Tree中一次检索最多需要h-1次I/O(根节点常驻内存),渐进复杂度为O(h)=O(logdN)

      f.一般实际应用中,出度d是非常大的数字,通常超过100,因此h非常小(通常不超过3)

    综上所述,如果我们采用B-Tree存储结构,搜索时I/O次数一般不会超过3次,所以用B-Tree作为索引结构效率是非常高的。

    6.2、B+tree性能分析

      a.从上面介绍我们知道,B树的搜索复杂度为O(h)=O(logdN),所以树的出度d越大,深度h就越小,I/O的次数就越少

      b.B+Tree恰恰可以增加出度d的宽度,因为每个节点大小为一个页大小,所以出度的上限取决于节点内key和data的大小

      c.由于B+Tree内节点去掉了data域,因此可以拥有更大的出度,从而拥有更好的性能

    6.3、B+tree的查找过程

      

      a.如果要查找数据项29,那么首先会把磁盘块1由磁盘加载到内存,此时发生一次IO

      b.在内存中用二分查找确定29在17和35之间,锁定磁盘块1的P2指针,内存时间因为非常短(相比磁盘的IO)可以忽略不计

      c.通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存,发生第二次IO

      d.29在26和30之间,锁定磁盘块3的P2指针

      e.通过指针加载磁盘块8到内存,发生第三次IO

      f.同时内存中做二分查找找到29,结束查询,总计三次IO

      结论:真实的情况是,3层的b+树可以表示上百万的数据,如果上百万的数据查找只需要三次IO,性能提高将是巨大的,如果没有索引,每个数据项都要发生一次IO,那么总共需要百万次的IO,显然成本非常非常高

四、Mysql索引实现

在MySQL中,索引属于存储引擎级别的概念,不同存储引擎对索引的实现方式是不同的,本文主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式。

   

  1、MyISAM实现索引

      1. MyISAM引擎使用B+Tree作为索引结构,叶节点的data域存放的是数据记录的地址。

      2. MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引。

      3. 如果指定的Key存在,则取出其data域的值,然后以data域的值为地址,读取相应数据记录。

      4. MyISAM的索引方式也叫做“非聚集”的,之所以这么称呼是为了与InnoDB的聚集索引区分。

  2.MyISAM索引实现原理图

    

    1.这里设表一共有三列,假设我们以Col1为主键,则上图是一个MyISAM表的主索引(Primary key)示意

    2.可以看出MyISAM的索引文件仅仅保存数据记录的地址

    

  3. InnoDB索引实现

  虽然InnoDB也使用B+Tree作为索引结构,但具体实现方式却与MyISAM截然不同。

   

    1、区别1:InnoDB的数据文件本身就是索引文件

      1. 从上文知道,MyISAM索引文件和数据文件是分离的,索引文件仅保存数据记录的地址。

      2. 而在InnoDB中,表数据文件本身就是按B+Tree组织的一个索引结构,这棵树的叶节点data域保存了完整的数据记录。

      3. 这个索引的key是数据表的主键,因此InnoDB表数据文件本身就是主索引。

    

    

      说明:

        可以看到叶节点包含了完整的数据记录,这种索引叫做聚集索引。

        因为InnoDB的数据文件本身要按主键聚集,所以InnoDB要求表必须有主键(MyISAM可以没有)

        如果没有显式指定,则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键

        如果不存在这种列,则MySQL自动为InnoDB表生成一个隐含字段作为主键,这个字段长度为6个字节,类型为长整形。

     

    2、区别2:InnoDB的辅助索引data域存储相应记录主键的值而不是地址

      1. 换句话说,InnoDB的所有辅助索引都引用主键作为data域。

      2. 这里以英文字符的ASCII码作为比较准则。

      3. 聚集索引这种实现方式使得按主键的搜索十分高效,但是辅助索引搜索需要检索两遍索引

      4. 首先检索辅助索引获得主键,然后用主键到主索引中检索获得记录。

    3、为什么不建议使用过长的字段作为主键

      1. 例如知道了InnoDB的索引实现后,就很容易明白为什么不建议使用过长的字段作为主键

      2. 因为所有辅助索引都引用主索引,过长的主索引会令辅助索引变得过大。

      3. 再例如,用非单调的字段作为主键在InnoDB中不是个好主意,因为InnoDB数据文件本身是一颗B+Tree,

      4. 非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整,十分低效,而使用自增字段作为主键则是一个很好的选择。

五、索引使用策略

  1、联合索引(复合索引)

      1. 联合索引其实很简单,相对于一般索引只有一个字段,联合索引可以为多个字段创建一个索引

      2. 它的原理也很简单,比如,我们在(a,b,c)字段上创建一个联合索引,则索引记录会首先按照A字段排序,然后再按照B字段排序然后再是C字段

      3. 其实联合索引的查找就跟查字典是一样的,先根据第一个字母查,然后再根据第二个字母查

      4. 或者只根据第一个字母查,但是不能跳过第一个字母从第二个字母开始查。这就是所谓的最左前缀原理。

      5. 联合索引的特点就是:

        1)第一个字段一定是有序的
        2)当第一个字段值相等的时候,第二个字段又是有序的,比如下表中当A=2时所有B的值是有序排列的,依次类推,当同一个B值得所有C字段是有序排列的

'''最左前缀原理'''

#### 1、以下的查询方式都可以用到索引
'''
select * from table where a=1;
select * from table where a=1 and b=2;
select * from table where a=1 and b=2 and c=3;
上面三个查询按照 (a ), (a,b ),(a,b,c )的顺序都可以利用到索引,这就是最左前缀匹配。
'''

#### 2、如果查询语句是:
'''
select * from table where a=1 and c=3; 那么只会用到索引a。
'''

#### 3、这样不会用的索引
'''
select * from table where b=2 and c=3; 因为没有用到最左前缀a,所以这个查询是用户到索引的。
'''
最左前缀查询原理

  

  2、前缀索引

      1. 前缀索引就是用列的前缀代替整个列作为索引key,当前缀长度合适时,可以做到既使得前缀索引的选择性接近全列索引

      2. 同时因为索引key变短而减少了索引文件的大小和维护开销。

      3. 一般来说以下情况可以使用前缀索引:

        1)字符串列(varchar,char,text等),需要进行全字段匹配或者前匹配。也就是=‘xxx’ 或者 like ‘xxx%’
        2)字符串本身可能比较长,而且前几个字符就开始不相同。(比如:收件地址、外国人的姓名)

      4. MySQL 前缀索引能有效减小索引文件的大小,提高索引的速度。

      5. 但是前缀索引也有它的坏处:MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引,也不能把它们用作覆盖索引(Covering Index)。

  3、索引优化策略

      说明:MySQL的优化主要分为结构优化(Scheme optimization)和查询优化(Query optimization)。

# 1、最左前缀匹配原则,上面讲到了
# 2、主键外键一定要建索引
# 3、对 where,on,group by,order by 中出现的列使用索引
# 4、尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,
# 5、为较长的字符串使用前缀索引

'''
# 6、不要过多创建索引, 权衡索引个数与DML之间关系,DML也就是插入、删除数据操作。
    这里需要权衡一个问题,建立索引的目的是为了提高查询效率的,但建立的索引过多,
    会影响插入、删除数据的速度,因为我们修改的表数据,索引也需要进行调整重建
'''

'''
# 7、对于like查询,”%”不要放在前面。
    SELECT * FROMhoudunwangWHEREunameLIKE'后盾%' -- 走索引 
    SELECT * FROMhoudunwangWHEREunameLIKE "%后盾%" -- 不走索引
'''

'''
# 8、查询where条件数据类型不匹配也无法使用索引 
    字符串与数字比较不使用索引; 
    CREATE TABLEa(achar(10)); 
    EXPLAIN SELECT * FROMaWHEREa="1" – 走索引 
    EXPLAIN SELECT * FROM a WHERE a=1 – 不走索引 
    正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因
'''
索引优化方案
建索引原则:

1.最左前缀匹配原则,非常重要的原则,mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配,
比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,
如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整。

2.=和in可以乱序,比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序,
mysql的查询优化器会帮你优化成索引可以识别的形式

3.尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*),表示字段不重复的比例,
比例越大我们扫描的记录数越少,唯一键的区分度是1,而一些状态、性别字段可能在大数据面前区分度就是0,
那可能有人会问,这个比例有什么经验值吗?使用场景不同,这个值也很难确定,
一般需要join的字段我们都要求是0.1以上,即平均1条扫描10条记录

4.索引列不能参与计算,保持列“干净”,比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引,
原因很简单,b+树中存的都是数据表中的字段值,但进行检索时,需要把所有元素都应用函数才能比较,
显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);

5.尽量的扩展索引,不要新建索引。比如表中已经有a的索引,现在要加(a,b)的索引,那么只需要修改原来的索引即可
索引建立原则

   

猜你喜欢

转载自www.cnblogs.com/ppzhang/p/10423360.html