• MySQL的B+Tree索引


    为什么要使用索引?

    最简单的方式实现数据查询:全表扫描,即将整张表的数据全部或者分批次加载进内存,由于存储的最小单位是块或者页,它们是由多行数据组成,然后逐块逐块或者逐页逐页地查找,这样查找的速度非常慢。优点:在数据量小比如只有几十行数据的情况下很快。但数据量大时不适用。更通常情况下,我们应该避免全表扫描,我们可以通过索引来大幅提升查询数据的速度。

    什么信息能够成为索引?

    能把记录限制在一定查找范围内的字段,比如键,唯一键,主键等

    B+ Tree更适合用来做索引原因:

    1.B+ 树的磁盘读写代价更低。因为它的非叶子节点只存储索引而不存储具体数据,因此其内部节点相对B Tree 更小。如果把所有内部节点的关键字存放在同一盘块中,这个盘块能容纳的关键字数量就更多,一次性读入内存中的需要查找的关键字也越多,相对来说,I/O次数就降低了。

    2.B+ 树查询效率更加稳定。其内部节点并不是最终指向文件内容的节点,而只是叶子节点中关键字的索引,所以任何关键字的查找必定有一条从根节点到叶子节点的路径。所以关键字查询的长度相同,导致每个数据的查找效率也几乎是相同的稳定的,都是0log(n)

    1. B+ 树更有利于对数据库的扫描。B+ 树只需要遍历叶子节点就可以对全部关键字信息的扫描,在做范围查询时效率很高。

    如何优化索引?

    1.哈希索引

    缺点:

    ①仅仅能满足“=”,“IN",不能使用范围查询。哈希索引比较的是进行哈希运算之后的哈希值,所以它只能用于等值的过滤,不能用于基于范围的查询,因为经过哈希运算之后的哈希值不能保证和原来的键值一样

    ②无法被用来避免数据的排序操作。由于哈希索引存储的是经过哈希运算之后的值,而且哈希值不一定和原来的键值一样,所以数据库无法利用索引的数据来避免任何排序运算。

    ③不能利用部分索引键查询。

    ④不能避免表扫描。哈希索引是将索引键通过哈希运算之后的哈希值和对应的行指针信息存放在一个bucket当中,由于不同的索引建会出现相同的哈希值,所以即使取出满足某个哈希键值的那些数据,也无法从哈希索引中直接完成查询,还是要通过访问bucket中的实际数据进行相应的比较。

    ⑤遇到大量Hash值相等的情况后性能并不一定就会比B树索引高。极端情况下所有数据可能插入到一个桶中,如果正好要查询最后一条数据,就变成线性的了。

    2.BitMap

    缺点:只适用于固定字段的值,而且锁的粒度非常大,不适用于并发场景,OLAP而不是OLTP

    密集索引和稀疏索引的区别?

    如何定位并优化慢查询sql?

    • 根据慢日志定位慢查询sql
    • 使用explain等工具分析sql
    • 修改sql或者尽量让sql走索引

    type关键字段:如果出现了all字段,则表示进行了全表扫描,效率非常低。

    最左匹配原则

    MySQL中的索引可以以一定顺序引用多列,这种索引叫作联合索引。如User表的name和city加联合索引就是(name,city),而最左前缀原则指的是,如果查询的时候查询条件精确匹配索引的左边连续一列或几列,则此列就可以被用到。如果查询条件为后面的一列或几列,则无法用到此索引。如下:

    select * from user where name=xx and city=xx ; //可以命中索引
    select * from user where name=xx ; // 可以命中索引
    select * from user where city=xx ; // 无法命中索引 
    

    通常让选择性最强的索引列放在前面。

    索引的选择性是指:不重复的索引值和记录总数的比值。最大值为 1,此时每个记录都有唯一的索引与其对应。选择性越高,每个记录的区分度越高,查询效率也越高。

    最左匹配原则的成因?

    mysql创建联合索引的规则是首先对联合索引最左边的索引字段的数据进行排序,然后在此基础上在对第二个索引进行排序,类似于“order by 字段1,order by 字段2,.......”。第一个字段绝对有序,第二个字段就是无序的了。因此通常情况下,直接使用第二个字段条件判断是用不到索引的。

    索引是建立的越多越好吗?

    • 数据量小的表不需要建立索引。建立索引会增加额外的索引开销
    • 数据变更需要维护索引,因此更多的索引意味着更多的成本
    • 更多的索引意味着也需要更多的空间

    索引的优点

    • 大大减少了服务器需要扫描的数据行数
    • 可以让服务器避免进行排序和分组,以及避免创建临时表(B+Tree索引本身就是有序的,可以用于ORDER BY和GROUP BY操作。临时表主要是在排序和分组过程中创建,不需要排序和分组,也就不需要创建临时表)
    • 将随机 I/O 变为顺序 I/O(B+Tree 索引是有序的,会将相邻的数据都存储在一起)

    索引的使用条件

    • 对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效;
    • 对于中到大型的表,索引就非常有效;
    • 但是对于特大型的表,建立和维护索引的代价将会随之增长。这种情况下,需要用到一种技术可以直接区分出需要查询的一组数据,而不是一条记录一条记录地匹配,例如可以使用分区技术
  • 相关阅读:
    poj 1475 Pushing Boxes 推箱子(双bfs)
    poj 1806 Frequent values(RMQ 统计次数) 详细讲解
    poj 2846 Repository
    poj Ping pong LA 4329 (树状数组统计数目)
    POJ 1962-Corporative Network (并查集)
    hdu 2217 Visit
    nyoj304 节能
    与R纠缠的两件事——rownames和子集--转载
    七步精通Python机器学习--转载
    win10专业版激活(亲测可用)
  • 原文地址:https://www.cnblogs.com/kyoner/p/11364704.html
Copyright © 2020-2023  润新知