索引相关知识

索引

为什么使用索引

? 一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，在生产环境中，我们遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，因此对查询语句的优化显然是重中之重。说起加速查询，就不得不提到索引了。

? 索引的目的在于提高查询效率，与我们查阅图书所用的目录是一个道理：先定位到章，然后定位到该章下的一个小节，然后找到页数。相似的例子还有：查字典，查火车车次，飞机航班等，下面内容看不懂的同学也没关系，能明白这个目录的道理就行了。 那么你想，书的目录占不占页数，这个页是不是也要存到硬盘里面，也占用硬盘空间。你再想，你在没有数据的情况下先建索引或者说目录快，还是已经存在好多的数据了，然后再去建索引，哪个快，肯定是没有数据的时候快，因为如果已经有了很多数据了，你再去根据这些数据建索引，是不是要将数据全部遍历一遍，然后根据数据建立索引。你再想，索引建立好之后再添加数据快，还是没有索引的时候添加数据快，索引是用来干什么的，是用来加速查询的，那对你写入数据会有什么影响，肯定是慢一些了，因为你但凡加入一些新的数据，都需要把索引或者说书的目录重新做一个，所以索引虽然会加快查询，但是会降低写入的效率。　　

? 索引的影响

? 1、在表中有大量数据的前提下，创建索引速度会很慢

? 2、在索引创建完毕后，对表的查询性能会发幅度提升，但是写性能会降低

? 本质都是：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。

? 数据库也是一样，但显然要复杂的多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段......这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的。而数据库实现比较复杂，一方面数据是保存在磁盘上的，另外一方面为了提高性能，每次又可以把部分数据读入内存来计算，因为我们知道访问磁盘的成本大概是访问内存的十万倍左右，所以简单的搜索树难以满足复杂的应用场景。

? 前面提到了访问磁盘，那么这里先简单介绍一下磁盘IO和预读，磁盘读取数据靠的是机械运动，每次读取数据花费的时间可以分为寻道时间、旋转延迟、传输时间三个部分，寻道时间指的是磁臂移动到指定磁道所需要的时间，主流磁盘一般在5ms以下；旋转延迟就是我们经常听说的磁盘转速，比如一个磁盘7200转/min，表示每分钟能转7200次，也就是说1秒钟能转120次，旋转延迟就是1/120/2 = 4.17ms，也就是半圈的时间（这里有两个时间：平均寻道时间，受限于目前的物理水平，大概是5ms的时间，找到磁道了，还需要找到你数据存在的那个点，寻点时间，这寻点时间的一个平均值就是半圈的时间，这个半圈时间叫做平均延迟时间，那么平均延迟时间加上平均寻道时间就是你找到一个数据所消耗的平均时间，大概9ms，其实机械硬盘慢主要是慢在这两个时间上了，当找到数据然后把数据拷贝到内存的时间是非常短暂的，和光速差不多了）；传输时间指的是从磁盘读出或将数据写入磁盘的时间，一般在零点几毫秒，相对于前两个时间可以忽略不计。那么访问一次磁盘的时间，即一次磁盘IO的时间约等于5+4.17 = 9ms左右，听起来还挺不错的，但要知道一台500 -MIPS（Million Instructions Per Second）的机器每秒可以执行5亿条指令，因为指令依靠的是电的性质，换句话说执行一次IO的消耗的时间段下cpu可以执行约450万条指令，数据库动辄十万百万乃至千万级数据，每次9毫秒的时间，显然是个灾难，所以我们要想办法降低IO次数。

索引原理

? 前面讲了索引的基本原理，数据库的复杂性，又讲了操作系统的相关知识，目的就是让大家了解，现在我们来看看索引怎么做到减少IO，加速查询的。任何一种数据结构都不是凭空产生的，一定会有它的背景和使用场景，我们现在总结一下，我们需要这种数据结构能够做些什么，其实很简单，那就是：每次查找数据时把磁盘IO次数控制在一个很小的数量级，最好是常数数量级。那么我们就想到如果一个高度可控的多路搜索树是否能满足需求呢？就这样，b+树应运而生，看下图：

? 如上图，是一颗b+树，最上层是树根，中间的是树枝，最下面是叶子节点，关于b+树的定义可以参见B+树，这里只说一些重点，浅蓝色的块我们称之为一个磁盘块或者叫做一个block块，这是操作系统一次IO往内存中读的内容，一个块对应四个扇区，可以看到每个磁盘块包含几个数据项（深蓝色所示，一个磁盘块里面包含多少数据，一个深蓝色的块表示一个数据，其实不是数据，后面有解释）和指针（黄色所示，看最上面一个，p1表示比上面深蓝色的那个17小的数据的位置在哪，看它指针指向的左边那个块，里面的数据都比17小，p2指向的是比17大比35小的磁盘块），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非叶子节点只不存储真实的数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。

? 如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。除了叶子节点，其他的树根啊树枝啊保存的就是数据的索引，他们是为你建立这种数据之间的关系而存在的。

? 索引字段要尽量的小：通过上面的分析，我们知道IO次数取决于b+数的高度h或者说层级，这个高度或者层级就是你每次查询数据的IO次数，假设当前数据表的数据为N，每个磁盘块的数据项的数量是m，则有h=㏒(m+1)N，当数据量N一定的情况下，m越大，h越小；而m = 磁盘块的大小 / 数据项的大小，磁盘块的大小也就是一个数据页的大小，是固定的，如果数据项占的空间越小，数据项的数量越多，树的高度越低。这就是为什么每个数据项，即索引字段要尽量的小，比如int占4字节，要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点，一旦放到内层节点，磁盘块的数据项会大幅度下降，导致树增高。当数据项等于1时将会退化成线性表

MySQL的常用索引

1.3.1 常用索引

主键索引PRIMARY：又称为聚集索引，每张表有且只能有一个，主键索引PRIMARY KEY：加速查找+约束（不为空、不能重复）

普通索引INDEX：加速查找，可以有多个

唯一索引：主键索引PRIMARY KEY：加速查找+约束（不为空、不能重复）

联合索引：多个字段联合起来作为索引
    -PRIMARY KEY(id,name):联合主键索引
    -UNIQUE(id,name):联合唯一索引
    -INDEX(id,name):联合普通索引

? 使用InnoDB存储引擎的时候，每建一个表，就需要给一个主键，是因为这个主键是InnoDB存储引擎的.idb文件来组织存储数据的依据或者说方式，也就是说InnoDB存储引擎在存储数据的时候默认就按照索引的那种树形结构来帮你存。这种索引，我们就称为聚集索引，也就是在聚集数据组织数据的时候，就用这种索引。InnoDB这么做就是为了加速查询效率，因为你经常会遇到基于主键来查询数据的情况，并且通常我们把id字段作为主键，第一点是因为id占用的数据空间不大，第二点是你经常会用到id来查数据。如果你的表有两个字段，一个id一个name，id为主键，当你查询的时候如果where后面的条件是name=多少多少，那么你就没有用到主键给你带来的加速查询的效果（需要主键之外的辅助索引），如果你用where id=多少多少，就会按照我们刚才上面说的哪种树形结构来给你找寻数据了（当然不仅仅有这种树形结构的数据结构类型），能够快速的帮你定位到数据块。这种聚集索引的特点是它会以id字段作为依据，去建立树形结构，但是叶子节点存的是你表中的一条完整记录，一条完整的数据。

索引操作

主键索引:
  创建的时候添加:
    Create table t1(
      Id int primary key,
    )
    Create table t1(
      Id int,
      Primary key(id)
    )

表创建完了之后添加
    Alter table 表名 add primary key(id)
删除主键索引:
    Alter table 表名 drop primary key;

唯一索引:
  Create table t1(
    Id int unique,
  )

  Create table t1(
    Id int,
    Unique key uni_name (id)
  )

表创建好之后添加唯一索引:
    alter table s1 add unique key  u_name(id);
删除唯一索引:
    Alter table s1 drop index u_name;

普通索引:
创建:
  Create table t1(
    Id int,
    Index index_name(id)
  )
表创建好之后添加普通索引:
    Alter table s1 add index index_name(id);
    Create index index_name on s1(id);

删除普通索引:
    Alter table s1 drop index u_name;
    DROP INDEX 索引名 ON 表名字;

将上面添加索引的字段变为多个就成了联合索引，例如：

联合主键索引
    Create table t1(
      Id int,
      name char(10),
      Primary key(id，name)
    )
联合唯一索引
    Create table t1(
    Id int,
    name char(10),
    Unique key uni_name (id，name)
  )
联合普通索引
    Create table t1(
    Id int,
    name char(10),
    Index index_name(id，name)
  )

创建表完成之后，再添加联合索引的方式和上面的给单个字段添加索引的方式相同。

测试索引

数据准备

#1. 准备表
create table s1(
  id int,
  name varchar(20),
  gender char(6),
  email varchar(50)
);

#2. 创建存储过程，实现批量插入记录，存储过程没什么特别的，将下面的代码到mysql中运行一下就可以了，注意，可能会花费挺长时间，因为数据量比较大，有300万条数据。
delimiter $$ #声明存储过程的结束符号为$$
create procedure auto_insert1()
BEGIN
    declare i int default 1;
    while(i<3000000)do
        insert into s1 values(i,'egon','male',concat('egon',i,'@oldboy'));
        set i=i+1;
    end while;
END$$ #$$结束
delimiter ; #重新声明分号为结束符号

#3. 查看存储过程
show create procedure auto_insert1\G 

#4. 调用存储过程
call auto_insert1();

测试示例

  1. 在没有索引的前提下测试查询速度。
mysql> select * from s1 where id=333333333;
Empty set (0.33 sec)

? 在表中已经存在大量数据的前提下，为某个字段段建立索引，建立速度会很慢

? 或者用alter table s1 add primary key(id);加主键，建索引很慢的。

? 在索引建立完毕后，以该字段为查询条件时，查询速度提升明显

　　　　

正确命中索引

? 并不是说我们创建了索引就一定会加快查询速度，若想利用索引达到预想的提高查询速度的效果，我们在添加索引时，必须遵循以下问题

  1. 范围问题，或者说条件不明确，条件中出现这些符号或关键字：>、>=、<、<=、!= 、between...and...、like

? 如果你写where id >1 and id <1000000;你会发现，随着你范围的增大，速度会越来越慢，会成倍的体现出来。

  1. 尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0。
  2. =和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式 
    #1、and与or的逻辑
    条件1 and 条件2:所有条件都成立才算成立，但凡要有一个条件不成立则最终结果不成立
    条件1 or 条件2:只要有一个条件成立则最终结果就成立

#2、and的工作原理
    条件：
        a = 10 and b = 'xxx' and c > 3 and d =4
    索引：
        制作联合索引(d,a,b,c)
    工作原理:  #如果是你找的话，你会怎么找，是不是从左到右一个一个的比较啊，首先你不能确定a这个字段是不是有索引，即便是有索引，也不一定能确保命中索引了（所谓命中索引，就是应用上了索引），mysql不会这么笨的，看下面mysql是怎么找的：
        索引的本质原理就是先不断的把查找范围缩小下来，然后再进行处理，对于连续多个and：mysql会按照联合索引，从左到右的顺序找一个区分度高的索引字段(这样便可以快速锁定很小的范围)，加速查询，即按照d—>a->b->c的顺序

#3、or的工作原理
    条件：
        a = 10 or b = 'xxx' or c > 3 or d =4
    索引：
        制作联合索引(d,a,b,c)

    工作原理:
        只要一个匹配成功就行，所以对于连续多个or：mysql会按照条件的顺序，从左到右依次判断，即a->b->c->d
  3. 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’)
  4. 最左匹配特性(针对联合索引的)

    最左前缀：顾名思义，就是最左优先，上一个博客中数据库我们创建了UNIQUE KEY uk_device (device_id,user_id,token)多列索引,相当于创建了(device_id)单列索引，(device_id,user_id)组合索引以及(device_id,user_id,token)组合索引。

    结论是索引键是（a_b_c）seclect * from table where a=‘ ‘;以下情况：

    ? 1：a= 可以命中索引，b= 不可以命中索引，c= 不可以命中索引。

    ? 2：a=‘’ and b=‘’可以命中，a=‘’ and c=‘’ 可以命中索引。

    ? 3：b=’‘and a=’‘可以命中索引， b=‘‘ and c=’‘ 不可以命中索引。

    ? 4：c=’‘ and a=’‘ 可以命中 索引，c=’‘ and b=’‘不可命中索引。

原文地址：https://www.cnblogs.com/zhufanyu/p/12129456.html

时间： 2024-10-04 23:29:44

索引相关知识的相关文章

MongoDB 索引相关知识

背景: MongoDB和MySQL一样,都会产生慢查询,所以都需要对其进行优化:包括创建索引.重构查询等.现在就说明在MongoDB下的索引相关知识点,可以通过这篇文章MongoDB 查询优化分析了解MongoDB慢查询的一些特点. 执行计划分析: 因为MongoDB也是BTree索引,所以使用上和MySQL大致一样.通过explain查看一个query的执行计划,来判断如何加索引,explain在3.0版本的时候做了一些改进,现在针对这2个版本进行分析: 3.0之前: zjy:PRIMARY>

mysql 索引相关知识

由where 1 =1 引发的思考 最近工作上被说了 说代码中不能用 where 1=1,当时觉得是应该可以用的,但是找不到什么理据, 而且mysql 语句优化这方面确实很薄弱 感觉自己mysql方面是知识还是不够哇 得好好研究研究 还有发现 很多知识点 光看的话根本记不住,也不深刻.还是得亲手实践下 so  ~~~ 挫折越多进步越快 1.关于sql语句大小问题 1)mysql默认情况下没有设置 root用户密码 给mysql的root用户设置密码先 [[email protected] ~]$

MySQL索引相关知识

MySQl索引创建 一.什么是索引? 索引用来快速地寻找那些具有特定值的记录,所有MySQL索引都以B-树的形式保存.如果没有索引,执行查询时MySQL必须从第一个记录开始扫描整个表的所有记录,直至找到符合要求的记录.表里面的记录数量越多,这个操作的代价就越高.如果作为搜索条件的列上已经创建了索引,MySQL无需扫描任何记录即可迅速得到目标记录所在的位置.如果表有1000个记录,通过索引查找记录至少要比顺序扫描记录快100倍. 假设我们创建了一个名为people的表: CREATE TABLE

python的list相关知识

关于list的相关知识 list01 = ['alex',12,65,'xiaodong',100,'chen',5] list02 = [67,7,'jinjiao_dawang','relax1949',53] #打印list01.list02 print(list01) print(list02) #列表截取.切片 print(list01[1]) print(list01[-2]) print(list01[1:3]) #列表重复 print(list01 * 3) #列表组合 prin

程序员面试笔试宝典学习记录（三）（数据库相关知识）

关系数据库系统与文件数据库系统的区别如下: (a)关系数据库系统的主要特征是数据的结构化,而文件数据库系统是数据的非结构化. (b)关系数据库系统中,用户看到的逻辑结构是二维表,而文件数据库系统中,基本元素是文件. (c)文件数据库系统可以实现多媒体文件管理,支持C/S工作模式. acid,指数据库事务正确执行的四个基本要素的缩写.包含:原子性(atomicity),一致性(consistency),隔离性(isolation),持久性(durability). 数据查询:select sele

数据库存储过程相关知识

(一) SET ANSI_NULLS {ON | OFF} 指定在对空值使用等于 (=) 和不等于 (<>) 比较运算符时,这些运算符的 SQL-92 遵从行为. 注释 SQL-92 标准要求对空值的等于 (=) 或不等于 (<>) 比较取值为 FALSE.当 SET ANSI_NULLS 为 ON 时,即使column_name 中存在空值,使用 WHERE column_name = NULL 的 SELECT 语句仍返回零行.即使column_name 中存在非空值,使用 W

oracle等待事件的相关知识

一． 等待事件的相关知识: 1.1 等待事件主要可以分为两类,即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件. 1). 空闲等待事件指ORACLE正等待某种工作,在诊断和优化数据库的时候,不用过多注意这部分事件. 2). 非空闲等待事件专门针对ORACLE的活动,指数据库任务或应用运行过程中发生的等待,这些等待事件是在调整数据库的时候需要关注与研究的. 在Oracle 10g中的等待事件有872个,11g中等待事件1116个. 我们可以通过v$event_name 视图来查看等待

【Linux驱动】文件描述符以及相关知识

1.文件描述符 Linux操作系统中,几乎所有的设备都被抽象成为设备文件.因此,当我们想对设备进行操作的时候可以直接去操作其相应的设备文件.设备文件即是文件,要想对文件进行操作,无非就是:打开文件.关闭文件.写入数据.读出数据等,它们分别对应的函数有open(),close(),write(),read(),就以其中的open()函数做一个分析.open函数的作用是打开一个文件. (1)它的定义:int open( const char * pathname, int flags); int o

Python 数据分析（二 本实验将学习利用 Python 数据聚合与分组运算，时间序列，金融与经济数据应用等相关知识

Python 数据分析(二) 本实验将学习利用 Python 数据聚合与分组运算,时间序列,金融与经济数据应用等相关知识 第1节 groupby 技术 第2节 数据聚合 第3节 分组级运算和转换 第4节 透视表和交叉表 第5节 时间序列 第6节 日期的规范.频率以及移动 第7节 时区处理 第8节 时期及算术运算 第9节 重采样及频率转换 第10节 时间序列绘图 groupby 技术 一.实验简介 Python 数据分析(二)需要同学们先行学完 Python 数据分析(一)的课程. 对数据集进行分