5、mysql索引优化(有哪些优化mysql索引的方式请举例)

  本篇文章为你整理了5、mysql索引优化(有哪些优化mysql索引的方式请举例)的详细内容,包含有mysql索引优化是什么意思 有哪些优化mysql索引的方式请举例 mysql 索引优先顺序 mysql8.0索引 5、mysql索引优化,希望能帮助你了解 5、mysql索引优化。

  想个问题,如果设计一个索引结构,使用哪种数据结构好呢?
 

  如果使用hash表肯定不太好,占用空间太大,每个数据下标位置是个链表
 

  如果使用二叉树会好一点,但不管是平衡二叉树还是红黑树,随着数据增多,都会引发一个数据的深度的问题,查个数值可能会走很多节点的索引。

  所以考虑多叉树,如:B树
 

  
 

  B树的好处:
 

  因为是多叉树,所以可以优化树深度的问题。查找快,可能在非叶子节点就查到结果结束掉。

  B树的问题:
 

  mysql在读取数据时候,走磁盘io,也就是页的整数倍,mysql默认读取数据是4页,1页是4k,读取一次就是16k,当读取完结果后,每个节点都存了16k数据,如果读了三次,就读了48k数据。
 

  如果每个节点都是16k大小,每次存入1条数据是1kb,那每个节点最多存入16条数据,那么3次io大概要承受16 * 16 * 16 = 4096条数据,也就是3层B树才支撑4096条数据,我们一般在公司里的数据随便一个mysql表最起码也几百万条了吧。
 

  我们想下,B树的磁盘块本身是个很小的空间,但是额外带上了很多data数据,大部分的磁盘空间都被data占用了,所以要优化。
 

  如果不存data,只在叶子节点存data数据就好了,非叶子节点不存数据,只存key和指针,这就是B+树。

  B+树:
 

  
 

  打个比方估算一下:
 

  非叶子节点不存data,每个节点是16kb大小,也就是16 * 1000个字节,每个节点不存data,只存10个字节的key值,那就是 16 * 1000 / 10 = 1600个,那最终就是4096加4个0,就是40960000数据。
 

  估算结果就是说3层的B+树,就可以承载千万级别的数据。

  MyISAM和InnoDB

  MyISAM和InnoDB都是使用的B+树的索引结构,但是有一些不一样

  
MyISAM的话有两个:
 

  
 

  对应的结构图:
 

  
 

  也就是说,InnoDB的话,数据和索引是放在一起的,如果是MyISAM的话,数据和索引是分开放的,这就决定了查询方式是不一样的。
 

  使用MyISAM如果查到了叶子节点,只查到了数据对应存放的内存地址,还需要通过这个地址再去获取具体的数据。所以肯定多读了一次io。

  
快速查找匹配WHERE子句的行

  从consideration中消除行,如果可以在多个索引之间进行选择,mysql通常会使用找到最少行的索引

  如果表具有多列索引,则优化器可以使用索引的任何最左前缀来查找行

  当有表连接的时候,从其他表检索行数据

  查找特定索引列的min或max值

  如果排序或分组时在可用索引的最左前缀上完成的,则对表进行排序和分组

  在某些情况下,可以优化查询以检索值而无需查询数据行

  回表
 

  普通索引的叶子节点存储的不是整行的数据,而是主键。
 

  比如给name列创建索引,会先查找name列的B+树,在叶子节点取到主键,然后去查主键的B+树,然后才能查到数据。
 

  查了两次,所以叫回表。

  覆盖索引
 

  上面的回表概念,没有第二次查找主键的B+树。
 

  比如一个sqlselect id form dual where name = 王二狗,和回表一样,先从name的普通索引查找到了主键,因为已经查到了主键id,这条sql的目的就是查id,所以不会再去查主键的B+树了,不需要进行回表。

  最左匹配
 

  当查询条件的列字段不是组合索引的最左边那个列字段,也就是没有对应上,就没有走索引(刚好这个列也没创建单独的索引)。

  索引下推
 

  索引下推是在mysql高版本才有的,
 

  比如要查数据,条件是where name = xx and age = xx,在mysql低版本的时候,是先查满足name条件的,然后在这基础上再去查一遍满足age条件的。
 

  在mysql高版本时候会自己优化成组合索引,在查询满足name条件的数据是,会直接筛选的不满足age条件的,这样就减少了io次数,这就是索引下推。

  基于哈希表的实现,只有精确匹配索引所有列的查询才有效,也就是说使用范围查找无效。
 

  在mysql中,只有memory的存储引擎显式支持哈希索引。
 

  哈希索引自身只需存储对应的hash值,所以索引的结构十分紧凑,这让哈希索引查找的速度非常快。
 

  哈希索引的限制:

  哈希索引只包含哈希值和行指针,而不存储字段值,索引不能使用索引中的值来避免读取行

  哈希索引数据并不是按照索引值顺序存储的,所以无法进行排序

  哈希索引不支持部分列匹配查找,哈希索引是使用索引列的全部内容来计算哈希值

  哈希索引支持等值比较查询,也不支持任何范围查询

  访问哈希索引的数据非常快,除非有很多哈希冲突,当出现哈希冲突的时候,存储引擎必须遍历链表中的所有行指针,逐行进行比较,直到找到所有符合条件的行

  哈希冲突比较多的话,维护的代价也会很高

  当包含多个列作为索引,需要注意的是正确的顺序依赖于该索引的查询,同时需要考虑如何更好的满足排序和分组的需要

  案例,建立组合索引a,b,c
 

  聚簇索引与非聚簇索引

  
聚簇索引
 

  不是单独的索引类型,而是一种数据存储方式,指的是数据行跟相邻的键值紧凑的存储在一起

  
数据访问更快,因为索引和数据保存在同一个树中

  使用覆盖索引扫描的查询可以直接使用页节点中的主键值

  
聚簇数据最大限度地提高了IO密集型应用的性能,如果数据全部在内存,那么聚簇索引就没有什么优势

  插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式

  更新聚簇索引列的代价很高,因为会强制将每个被更新的行移动到新的位置

  基于聚簇索引的表在插入新行,或者主键被更新导致需要移动行的时候,可能面临页分裂的问题

  聚簇索引可能导致全表扫描变慢,尤其是行比较稀疏,或者由于页分裂导致数据存储不连续的时候

  
如果一个索引包含所有需要查询的字段的值,我们称之为覆盖索引

  不是所有类型的索引都可以称为覆盖索引,覆盖索引必须要存储索引列的值

  不同的存储实现覆盖索引的方式不同,不是所有的引擎都支持覆盖索引,memory不支持覆盖索引

  优势:

  索引条目通常远小于数据行大小,如果只需要读取索引,那么mysql就会极大的较少数据访问量

  因为索引是按照列值顺序存储的,所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多

  一些存储引擎如MYISAM在内存中只缓存索引,数据则依赖于操作系统来缓存,因此要访问数据需要一次系统调用,这可能会导致严重的性能问题

  由于INNODB的聚簇索引,覆盖索引对INNODB表特别有用

  案例:

  当发起一个被索引覆盖的查询时,在explain的extra列可以看到using index的信息,此时就使用了覆盖索引

  

mysql explain select store_id,film_id from inventory\G

 

  *************************** 1. row ***************************

   id: 1

   select_type: SIMPLE

   table: inventory

   partitions: NULL

   type: index

  possible_keys: NULL

   key: idx_store_id_film_id

   key_len: 3

   ref: NULL

   rows: 4581

   filtered: 100.00

   Extra: Using index

  1 row in set, 1 warning (0.01 sec)

  

 

  在大多数存储引擎中,覆盖索引只能覆盖那些只访问索引中部分列的查询。不过,可以进一步的进行优化,可以使用innodb的二级索引来覆盖查询。
 

  例如:actor使用innodb存储引擎,并在last_name字段又二级索引,虽然该索引的列不包括主键actor_id,但也能够用于对actor_id做覆盖查询

  

mysql explain select actor_id,last_name from actor where last_name=HOPPER\G

 

  *************************** 1. row ***************************

   id: 1

   select_type: SIMPLE

   table: actor

   partitions: NULL

   type: ref

  possible_keys: idx_actor_last_name

   key: idx_actor_last_name

   key_len: 137

   ref: const

   rows: 2

   filtered: 100.00

   Extra: Using index

  1 row in set, 1 warning (0.00 sec)

  

 

  优化小细节

  当使用索引列进行查询的时候尽量不要使用表达式,把计算放到业务层而不是数据库层

  

select actor_id from actor where actor_id=4;

 

  err sql:

  select actor_id from actor where actor_id+1=5;

  

 

  尽量使用主键查询,而不是其他索引,因此主键查询不会触发回表查询

  使用前缀索引

  有时候需要索引很长的字符串,这会让索引变的大且慢,通常情况下可以使用某个列开始的部分字符串,这样大大的节约索引空间,从而提高索引效率,但这会降低索引的选择性,索引的选择性是指不重复的索引值和数据表记录总数的比值,范围从1/#T到1之间。索引的选择性越高则查询效率越高,因为选择性更高的索引可以让mysql在查找的时候过滤掉更多的行。
 

  ​ 一般情况下某个列前缀的选择性也是足够高的,足以满足查询的性能,但是对应BLOB,TEXT,VARCHAR类型的列,必须要使用前缀索引,因为mysql不允许索引这些列的完整长度,使用该方法的诀窍在于要选择足够长的前缀以保证较高的选择性,通过又不能太长。

  案例演示:

  

--创建数据表

 

  create table citydemo(city varchar(50) not null);

  insert into citydemo(city) select city from city;

  --重复执行5次下面的sql语句

  insert into citydemo(city) select city from citydemo;

  --更新城市表的名称

  update citydemo set city=(select city from city order by rand() limit 1);

  --查找最常见的城市列表,发现每个值都出现45-65次,

  select count(*) as cnt,city from citydemo group by city order by cnt desc limit 10;

  --查找最频繁出现的城市前缀,先从3个前缀字母开始,发现比原来出现的次数更多,可以分别截取多个字符查看城市出现的次数

  select count(*) as cnt,left(city,3) as pref from citydemo group by pref order by cnt desc limit 10;

  select count(*) as cnt,left(city,7) as pref from citydemo group by pref order by cnt desc limit 10;

  --此时前缀的选择性接近于完整列的选择性

  --还可以通过另外一种方式来计算完整列的选择性,可以看到当前缀长度到达7之后,再增加前缀长度,选择性提升的幅度已经很小了

  select count(distinct left(city,3))/count(*) as sel3,

  count(distinct left(city,4))/count(*) as sel4,

  count(distinct left(city,5))/count(*) as sel5,

  count(distinct left(city,6))/count(*) as sel6,

  count(distinct left(city,7))/count(*) as sel7,

  count(distinct left(city,8))/count(*) as sel8

  from citydemo;

  --计算完成之后可以创建前缀索引

  alter table citydemo add key(city(7));

  --注意:前缀索引是一种能使索引更小更快的有效方法,但是也包含缺点:mysql无法使用前缀索引做order by 和 group by。

  

 

  一般在使用查询时候,经常会用到order by,但是用order by效率会很低,因为会进行全表扫描,但如果用索引列的字段作为查询条件就会提高效率,而索引本身也是有序的,刚好可以使用order by

  all, in, or

  union all,in,or都能够使用索引,但是推荐使用in
 

  看下如下sql:

  

explain select * from actor where actor_id = 1 union all select * from actor where actor_id = 2;

 

  explain select * from actor where actor_id in (1,2);

  explain select * from actor where actor_id = 1 or actor_id =2;

  

 

  这三个sql查的结果都是一样的,但是推荐使用in

  强制类型转换会全表扫描

  

explain select * from user where phone=13800001234; 不会触发索引

 

  explain select * from user where phone=13800001234; 触发索引

  

 

  更新频繁不宜建索引

  更新十分频繁,数据区分度不高的字段上不宜建立索引

  更新会变更B+树,更新频繁的字段建议索引会大大降低数据库性能

  类似于性别这类区分不大的属性,建立索引是没有意义的,不能有效的过滤数据,

  一般区分度在80%以上的时候就可以建立索引,区分度可以使用 count(distinct(列名))/count(*) 来计算

  索引列不允许为null

  创建索引的列,不允许为null,可能会得到不符合预期的结果
 

  当需要进行表连接的时候,最好不要超过三张表,因为需要join的字段,数据类型必须一致

  尽量使用limit

  能使用limit的时候尽量使用limit
 

  limit是用来干嘛的?
 

  如果回答用来做分页的,不太对。
 

  应该说,是用来做限制输出的。
 

  如果使用了limit,当查找数据到了对应数量时候,就不会往下继续查找。
 

  如果查找1-5条数据,就会优化很多,如果查找第20001行,都快接近全表扫描了,也不算优化了。

  索引建议在5个以内

  单表索引建议控制在5个以内
 

  单索引字段数不允许超过5个(组合索引)

  创建索引的时候应该避免以下错误概念:
 

  索引越多越好
 

  过早优化,在不了解系统的情况下进行优化

  

show status like Handler_read%;

 

  

 

  
 

  Handler_read_first:读取索引第一个条目的次数
 

  Handler_read_key:通过index获取数据的次数
 

  Handler_read_last:读取索引最后一个条目的次数
 

  Handler_read_next:通过索引读取下一条数据的次数
 

  Handler_read_prev:通过索引读取上一条数据的次数
 

  Handler_read_rnd:从固定位置读取数据的次数
 

  Handler_read_rnd_next:从数据节点读取下一条数据的次数

  索引优化分析案例

  预先准备好数据

  

SET FOREIGN_KEY_CHECKS=0;

 

  DROP TABLE IF EXISTS `itdragon_order_list`;

  CREATE TABLE `itdragon_order_list` (

   `id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT 主键id,默认自增长,

   `transaction_id` varchar(150) DEFAULT NULL COMMENT 交易号,

   `gross` double DEFAULT NULL COMMENT 毛收入(RMB),

   `net` double DEFAULT NULL COMMENT 净收入(RMB),

   `stock_id` int(11) DEFAULT NULL COMMENT 发货仓库,

   `order_status` int(11) DEFAULT NULL COMMENT 订单状态,

   `descript` varchar(255) DEFAULT NULL COMMENT 客服备注,

   `finance_descript` varchar(255) DEFAULT NULL COMMENT 财务备注,

   `create_type` varchar(100) DEFAULT NULL COMMENT 创建类型,

   `order_level` int(11) DEFAULT NULL COMMENT 订单级别,

   `input_user` varchar(20) DEFAULT NULL COMMENT 录入人,

   `input_date` varchar(20) DEFAULT NULL COMMENT 录入时间,

   PRIMARY KEY (`id`)

  ) ENGINE=InnoDB AUTO_INCREMENT=10003 DEFAULT CHARSET=utf8;

  INSERT INTO itdragon_order_list VALUES (10000, 81X97310V32236260E, 6.6, 6.13, 1, 10, ok, ok, auto, 1, itdragon, 2017-08-28 17:01:49);

  INSERT INTO itdragon_order_list VALUES (10001, 61525478BB371361Q, 18.88, 18.79, 1, 10, ok, ok, auto, 1, itdragon, 2017-08-18 17:01:50);

  INSERT INTO itdragon_order_list VALUES (10002, 5RT64180WE555861V, 20.18, 20.17, 1, 10, ok, ok, auto, 1, itdragon, 2017-09-08 17:01:49);

  

 

  逐步开始进行优化:

  第一个案例:

  

select * from itdragon_order_list where transaction_id = "81X97310V32236260E";

 

  --通过查看执行计划发现type=all,需要进行全表扫描

  explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";

  --优化一、为transaction_id创建唯一索引

   create unique index idx_order_transaID on itdragon_order_list (transaction_id);

  --当创建索引之后,唯一索引对应的type是const,通过索引一次就可以找到结果,普通索引对应的type是ref,表示非唯一性索引赛秒,找到值还要进行扫描,直到将索引文件扫描完为止,显而易见,const的性能要高于ref

   explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";

   --优化二、使用覆盖索引,查询的结果变成 transaction_id,当extra出现using index,表示使用了覆盖索引

   explain select transaction_id from itdragon_order_list where transaction_id = "81X97310V32236260E";

  

 

  第二个案例

  

--创建复合索引

 

  create index idx_order_levelDate on itdragon_order_list (order_level,input_date);

  --创建索引之后发现跟没有创建索引一样,都是全表扫描,都是文件排序

  explain select * from itdragon_order_list order by order_level,input_date;

  --可以使用force index强制指定索引

  explain select * from itdragon_order_list force index(idx_order_levelDate) order by order_level,input_date;

  --其实给订单排序意义不大,给订单级别添加索引意义也不大,因此可以先确定order_level的值,然后再给input_date排序

  explain select * from itdragon_order_list where order_level=3 order by input_date;

  

 

  以上就是5、mysql索引优化(有哪些优化mysql索引的方式请举例)的详细内容,想要了解更多 5、mysql索引优化的内容,请持续关注盛行IT软件开发工作室。

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: