zoukankan      html  css  js  c++  java
  • 索引

    索引

    创建索引的目的是减小查询时间,提高查询效率。减少磁盘的读取次数

    1. 索引的含义

    ​ 索引是一个排序的列表,在这个列表中存储着索引的值和包含这个值的数据所在行的物理地址,在数据十分庞大的时候,索引可以大大加快查询的速度,这是因为使用索引后可以不用扫描全表来定位某行的数据,而是先通过索引表找到该行数据对应的物理地址然后访问相应的数据。

    2.索引的原理

    ​ 索引一般以文件的形式存储在磁盘中,索引的存储原理是以空间换取时间。未添加索引时查询是全局扫描,有多少数据就要扫描多少条数据。添加索引后,会将建立的索引的key添加到B-Tree上;B树的特点就是适合在磁盘等直接存储设备上组织动态查找表,每次以索引进行条件查询时,会去树上根据key值直接进行搜索。

    3.索引数据结构 :

    二叉树、 红黑树、 Hash表、 B-Tree。

    不同的存储引擎索引的数据结构不同

    4.与索引数据结构相关的计算机原理

    两种类型的存储:计算机系统一般包含两种类型的存储,计算机主存(RAM)和外部存储器(如硬盘、CD、SSD等)。主存的读取速度快,内存小。相对于主存,外部磁盘的数据读取速率要比主从慢好几个数量级,内存大。实际数据库中数据都是存储到外部存储器的。

    主存存储原理:当系统需要读取主存时,则将地址信号放到地址总线上传给主存,主存读到地址信号后,解析信号并定位到指定存储单元,然后将此存储单元数据放到数据总线上,供其它部件读取。写主存的过程类似,系统将要写入单元地址和数据分别放在地址总线和数据总线上,主存读取两个总线的内容,做相应的写操作。

    磁盘存储原理:索引一般以文件形式存储在磁盘上,索引检索需要磁盘I/O操作。与主存不同,磁盘I/O存在机械运动耗费,因此磁盘I/O的时间消耗是巨大的。磁盘读取数据靠的是机械运动,当需要从磁盘读取数据时,系统会将数据逻辑地址传给磁盘,磁盘的控制电路按照寻址逻辑将逻辑地址翻译成物理地址,即确定要读的数据在哪个磁道,哪个扇区。为了读取这个扇区的数据,需要将磁头放到这个扇区上方,为了实现这一点,磁头需要移动对准相应磁道,这个过程叫做寻道,所耗费时间叫做寻道时间,然后磁盘旋转将目标扇区旋转到磁头下,这个过程耗费的时间叫做旋转时间,最后便是对读取数据的传输。 所以每次读取数据花费的时间可以分为寻道时间、旋转延迟、传输时间三个部分。

    局部性原理和磁盘预读:磁盘的存取本身比主存慢,加上磁盘的机械运动消耗使得磁盘的存取更慢。所以为了提高查询速度就要减少减少磁盘I/O。为了达到这个目的,磁盘往往不是严格按需读取,而是每次都会预读,即使只需要一个字节,磁盘也会从这个位置开始,顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理:当一个数据被用到时,其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。

    ​ 由于磁盘顺序读取的效率很高(不需要寻道时间,只需很少的旋转时间),因此对于具有局部性的程序来说,预读可以提高I/O效率。预读的长度一般为页(page)的整倍数。页是计算机管理存储器的逻辑块,硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块,每个存储块称为一页(在许多操作系统中,页得大小通常为4k),主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时,会触发一个缺页异常,此时系统会向磁盘发出读盘信号,磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中,然后异常返回,程序继续运行。

    5.MySQL的存储引擎

    image-20210324122441540

    MySQl默认的存储引擎是InnoDB: InnoDB 底层索引的数据结构为B+Tree;(B+Tree是B-Tree的变种)

    6.B-Tree和B+Tree,Hash的区别

    B-Tree

    ​ 每个节点都存储key和data,所有节点组成这棵树,并且叶子节点指针为null。

    img

    B+Tree

    	只有叶子节点存储data,叶子节点包含了这棵树的所有键值,叶子节点存储一个指向相邻叶子节点的指针。
    

    img

    Hash

    Hash 索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引。

    (1)Hash 索引仅仅能满足"=","IN"和"<=>"查询,不能使用范围查询。

    由于 Hash 索引比较的是进行 Hash 运算之后的 Hash 值,所以它只能用于等值的过滤,不能用于基于范围的过滤,因为经过相应的 Hash 算法处理之后的 Hash 值的大小关系,并不能保证和Hash运算前完全一样。

    (2)Hash 索引无法被用来避免数据的排序操作。

    由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash 值,而且Hash值的大小关系并不一定和 Hash 运算前的键值完全一样,所以数据库无法利用索引的数据来避免任何排序运算;

    (3)Hash 索引不能利用部分索引键查询。

    对于组合索引,Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值,而不是单独计算 Hash 值,所以通过组合索引的前面一个或几个索引键进行查询的时候,Hash 索引也无法被利用。

    (4)Hash 索引在任何时候都不能避免表扫描。

    前面已经知道,Hash 索引是将索引键通过 Hash 运算之后,将 Hash运算结果的 Hash 值和所对应的行指针信息存放于一个 Hash 表中,由于不同索引键存在相同 Hash 值,所以即使取满足某个 Hash 键值的数据的记录条数,也无法从 Hash 索引中直接完成查询,还是要通过访问表中的实际数据进行相应的比较,并得到相应的结果。

    (5)Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。

    对于选择性比较低的索引键,如果创建 Hash 索引,那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦,会浪费多次表数据的访问,而造成整体性能低下

    7.explain

    explain模拟执行SQL语句,对SQL语句进行分析并输出详细信息,便于开发人员进行优化操作。

    explain的详细信息:

    • id:执行顺序(先执行id值大的,相同id值先执行前面的)

    • select_type:查询的类型

      • SIMPLE, 表示此查询不包含 UNION 查询或子查询
      • PRIMARY, 表示此查询是最外层的查询
      • UNION, 表示此查询是 UNION 的第二或随后的查询
      • DEPENDENT UNION, UNION 中的第二个或后面的查询语句, 取决于外面的查询
      • UNION RESULT, UNION 的结果
      • SUBQUERY, 子查询中的第一个 SELECT
      • DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.
    • table:查询的表名

    • partitions:查询进行匹配分区

    • type:判断查询是否高效的重要依据

      • system: 表中只有一条数据. 这个类型是特殊的 const 类型.
      • const: 针对主键或唯一索引的等值查询扫描, 最多只返回一行数据. const 查询速度非常快, 因为它仅仅读取一次即可.
      • eq_ref: 此类型通常出现在多表的 join 查询, 表示对于前表的每一个结果, 都只能匹配到后表的一行结果. 并且查询的比较操作通常是 =, 查询效率较高.
      • ref: 此类型通常出现在多表的 join 查询, 针对于非唯一或非主键索引, 或者是使用了 最左前缀 规则索引的查询.
      • range: 表示使用索引范围查询, 通过索引字段范围获取表中部分数据记录. 这个类型通常出现在 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, IN() 操作中.
      • index: 表示全索引扫描(full index scan), 和 ALL 类型类似, 只不过 ALL 类型是全表扫描, 而 index 类型则仅仅扫描所有的索引, 而不扫描数据.
      • ALL: 表示全表扫描, 这个类型的查询是性能最差的查询之一. 通常来说, 我们的查询不应该出现 ALL 类型的查询, 因为这样的查询在数据量大的情况下, 对数据库的性能是巨大的灾难. 如一个查询是 ALL 类型查询, 那么一般来说可以对相应的字段添加索引来避免.
    • possible_keys:能够使用到的索引

    • key:实际用到的索引

    • key_len:查看索引是否全部被使用(值越大越好)

    • rows:扫描的数据行数(值越小越好)

    • Extra:额外信息

      • Using filesort:当 Extra 中有 Using filesort 时, 表示 MySQL 需额外的排序操作, 不能通过索引顺序达到排序效果. 一般有 Using filesort, 都建议优化去掉, 因为这样的查询 CPU 资源消耗大.

      • Using index
        "覆盖索引扫描", 表示查询在索引树中就可查找所需数据, 不用扫描表数据文件, 往往说明性能不错

      • Using temporary
        查询有使用临时表, 一般出现于排序, 分组和多表 join 的情况, 查询效率不高, 建议优化.

    8.索引的类型

    • 普通索引:单列索引是最基本的索引,它没有任何限制。
    • 组合索引:组合索引是在多个字段上创建的索引。组合索引遵守“最左前缀”原则即在查询条件中使用了组合索引的第一个字段,索引才会被使用。
    • 唯一索引:唯一索引和普通索引类似,主要的区别在于,唯一索引限制列的值必须唯一,但允许存在空值(只允许存在一条空值)。
    • 主键索引:主键索引是一种特殊的唯一索引,一个表只能有一个主键,不允许有空值。
    • 全文索引:全文索引主要用来查找文本中的关键字,而不是直接与索引中的值相比较。fulltext索引跟其它索引大不相同,它更像是一个搜索引擎,而不是简单的where语句的参数匹配。fulltext索引配合match against操作使用,而不是一般的where语句加like。目前只有char、varchar,text 列上可以创建全文索引。

    创建索引的语句

    CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type]

    on tbl_nam(index_col_name,……)

    删除索引

    DROP INDEX index_name ON tbl_name

    9.设置索引的规则

    1.最适合索引的列是出现在where子句中的列,或连接子句中指定的列,而不是出现在select关键字后的选择列表中的列。
    2.索引的列的基数越大,索引的效果越好。
    3.尽量使用短索引。能够节省大量索引空间,也可能使查询更快。
    4.不要过度索引。索引都要占用额外的磁盘空间,并降低写操作的性能。在修改表的内容时,索引必须进行更新,有时可能需要重构。

    10.注意事项

    1.索引不会包含有null值的列

    只要列中包含有null值都将不会被包含在索引中,复合索引中只要有一列含有null值,那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为null。

    2.使用短索引

    对串列进行索引,如果可能应该指定一个前缀长度。例如,如果有一个char(255)的列,如果在前10个或20个字符内,多数值是惟一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

    3.索引列排序

    查询只使用一个索引,因此如果where子句中已经使用了索引的话,那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作;尽量不要包含多个列的排序,如果需要最好给这些列创建复合索引。

    4.like语句操作

    一般情况下不推荐使用like操作,如果非使用不可,如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

    5.不要在列上进行运算

    这将导致索引失效而进行全表扫描

    6.不使用not in和<>操作

    11.索引的优缺点

    索引的优缺点:可以快速检索,减少I/O次数,加快检索速度;根据索引分组和排序,可以加快分组和排序;

    索引本身也是表,因此会占用存储空间,一般来说,索引表占用的空间的数据表的1.5倍;索引表的维护和创建需要时间成本,这个成本随着数据量增大而增大;构建索引会降低数据表的修改操作(删除,添加,修改)的效率,因为在修改数据表的同时还需要修改索引表;

  • 相关阅读:
    linux查看与设置主机名
    为什么用户主目录下.bash_profile没有自动执行
    sqlplus查看服务名
    linux之cp/scp命令+scp命令详解
    查看磁盘使用量
    yum源
    微软输入法删除
    Android下 ionic view 无法登录
    inline-block在ie6中的经典bug
    Apache端口配置
  • 原文地址:https://www.cnblogs.com/wanglong1/p/14927852.html
Copyright © 2011-2022 走看看