一. MySQL 索引概述

假设执行一条查询语句,在没有索引的情况下默认会通过全表搜秒,将获取到的数据与查询语句中的查询条件进行判断,假设表中的数据时百万级,效率会非常慢,所以创建索引,通过索引查询

可以简单理解为为了提高查询效率,给添加一个或多个索引,创建一个像目录一样的索引文件,是存在硬盘上的
mysql 索引数据结构支持 :hash, 平衡二叉树, b树, b+树等,通常采用b+树实现
Linux查看索引文件: /var/lib/mysql

mysql 服务器查询数据的执行过程

在这里插入图片描述

二. 索引算法简单解释

1. hash

以Map集合hash为例来说明,调用hashCode()方法获取到一个唯一的hash值,根据该hash值确定当前数据在集合中的存放位置,数据库中当查询数据时直接通过hash值去获取,提高查询效率
问题: 在存储数据时发生hash冲突,需要全表hash,重新计算每个数据的hash值,重新排列,hash只满足"=","IN”和“<=>”查询,不能范围查询,因为经过hash算法处理后的hash值的大小关系，并不能保证与处理前的hash大小关系对应,由于这个原因,也无法通过hash对数据进行排序,并且无法进行组合索引

2. 平衡二叉树

每个节点最多有两个子树的树结构,“左子树”和“右子树”,获取一个中间值为跟节点,后续按照数据的大小与中间值进行比对将数据放入二叉树的指定节点上,在查询时有点像二分查找,折半查找提高查询效率
通过下图解释查询过程,假设查询10,会执行四次查询,有四次IO操作(io操作读取硬盘数据到内存中的动作,第一次读取硬盘数据到内存中4判断大于4,第二次读取到8判断大于8----->最终读取到10)
平衡二叉树支持范围查询,但是有个回旋动作,假设查询大于5的数据,首先会查询到5,然后一个一个的回旋判断6,7,8----一直到获取到所有的大于5的数据,效率比较低

3. b树

在平衡二叉树基础上进行了改进,在平衡二叉树中,树的高度决定了查询时的io次数,b树的一个节点上可以存放多个数据,减少数据高度,减少io操作(下图中查询10只需要2次io操作),范围查询时与平衡二叉树相同需要回旋,效率较低
在这里插入图片描述

4. b+树

在b树的基础上区分叶子节点与非叶子节点,将数据分为key—value的形式,所有数据保存在叶子节点上,并且叶子节点中使用链表对所有数据进行了排序,在生成树时,非叶子节点上只存储了该数据该数据的key,通过该key可以直接在叶子节点上找到该数据,由于使用链表进行了排序在范围查询时不需要回旋,该范围以前的就是大于,以后的就是小于
在这里插入图片描述

三. MyISAM 与 InnoDB

mysql5.5之前使用MyISAM 作为搜索引擎,5.5以后使用InnoDB 做为搜索引擎,两个都是使用B+树,做为索引数据结构,不同的是,叶子节点中value值存放的数据不同,MyISAM的叶子节点value中存放的是指向当前数据的地址值,InnoDB中value值直接存放的是当前数据
MyISAM 不支持事物,不支持外键,不支持行锁,InnoDB 支持事物,支持外键,支持行锁
在使用InnoDB时,会自动添加一个主键索引,

通过安装的mysql中my.ini配置文件配置搜索引擎: default-storage-engine=INNODB
创建表时添加innodb搜索引擎: CREATE TABLE ‘表名’( ‘列明’ 数据类型其它校验,…,primary key(‘主键字段’)) ENGINE=InnoDB DEAULT CHARSET=utf8;
手动修改搜索引擎 : ALERT TABLE 表名 ENGINE=InnoDB

四. 索引的创建

索引分为主键引,唯一索引,全文索引, 多列组合索引, 普通索引,

主键索引: ALTER TABLE 表明 ADD PRIMARY KEY ( 主键字段 )
唯一索引: ALTER TABLE table_name ADD UNIQUE ( column )
全文索引: ALTER TABLE table_name ADD FULLTEXT ( column)
多列组合索引: ALTER TABLE table_name ADD INDEX index_name ( column1, column2, column3 )
普通索引: ALTER TABLE table_name ADD INDEX index_name ( column )

索引的设计规范

限制表中的索引数量,并不是越多越好,建议不超过5个(mysql在查询时首先会预估是否能命中,如果不能命中会使用优化器根据索引进行评估生成一个最好的执行计划,如果索引过多时,会增加mysql优化器生成执行计划的时间)
Innodb是按照主键索引的顺序来组织表的(要求每个Innodb表都有一个主键,如果没有主键Innodb会优先选择第一个非空,唯一的列作为主键,如果没有非空且唯一的列,Innodb默认会生成一个有六个字节的主键,但是该主键性能不是最好的)
常见增加索引列建议(主键索引以外的)创建在select,update语句的where字段,或包含在order by, group by, distince 等字段上创建,或join的关联列上
区分度最高的列放在联合索引的最左侧—>字段长度小的列放在联合索引的最左侧—>使用最频繁的列放在联合索引的最左侧(左前缀原则,原因是多个列排列创建联合索引,索引底层采用B+树数据结构,假设在查询时,where条件中左侧第一个列没有使用索引,或者使用了联合索引中非最左侧的列,通过该索引key找不到子节点,所以会走全表扫描)
避免重复索引,冗余索引
对于频繁查询的数据优先考虑使用覆盖索引
尽量避免使用外键(通过业务去关联)

EXPLAIN 查询sql执行计划

EXPLAIN SELECT * FROM 表名通过EXPLAIN+SQL语句,查看该语句的执行计划,查询耗时时间,是否使用索引,使用了几个索引等…,分析优进行优化,借用大神整理的EXPLAIN用法

#where条件中snapshot_id 为主键,通过EXPLAIN分析执行计划中的type为const,possible_keys为PRIMARY 使用主键索引
EXPLAIN SELECT * FROM express_customer_snapshot where snapshot_id='123456';
#where条件中'customer_name'字段添加了普通索引,EXPLAIN查看执行计划type为 ref, possible_keys 为index_name
EXPLAIN SELECT * FROM express_customer_snapshot where customer_name='bbb';
#查看EXPLAIN执行计划,possible_keys为'PRIMARY,index_name'使用了两个索引
EXPLAIN SELECT * FROM express_customer_snapshot where snapshot_id='123456' and customer_name='bbb';
#查看EXPLAIN执行计划,where条件字段中没有添加索引,type为ALL全表扫描
EXPLAIN SELECT * FROM express_customer_snapshot where operate_user_id='ccc';

分析执行计划,在某些时候索引会失效,总结:

避免使用模糊查询防止走全表扫描
where+group by 时,先where后分组
避免使用 !=,>,<
避免使用or,推荐union all
避免使用in与not in,使用exists

五. MySQL 慢查询

什么是慢查询: 假设执行一条查询sql语句,在指定时间内没有返回执行结果,说明查询过慢,对这条执行语句进行日志记录,慢查询就是指记录的这个日志
查询当前mysql服务器慢查询的配置(默认是关闭,开启后默认10未返回结果进行慢查询日志记录): show variables like ‘slow_query%’ 下方的’slow_query_log_file’ 文件路径就是记录慢查询日志的文件
开启慢查询: SET GLOBAL SLOW_QUERY_LOG=‘ON’;
查询慢查询记录日志时间: SHOW VARIABLES LIKE ‘long_query_time’;
修改记录慢查询日志的触发时间(多长时间内未返回结果进行记录,注意点由于保持当前会话,修改完毕后需要重启数据库连接,再去查看才会生效): SET GLOBAL LONG_QUERY_TIME=5;
开启慢查询以后可以使用pt-query-digest或Mysqdumpslow工具对慢查询日志进行分析,对sql进行优化处理