5、mysql索引优化

B+树

想个问题，如果设计一个索引结构，使用哪种数据结构好呢？
如果使用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+树的索引结构，但是有一些不一样

InnoDB的话，同一个表面只有一个文件：

对应的结构图：

如果查到了叶子节点，就直接查到了数据
MyISAM的话有两个：

对应的结构图：

也就是说，InnoDB的话，数据和索引是放在一起的，如果是MyISAM的话，数据和索引是分开放的，这就决定了查询方式是不一样的。
使用MyISAM如果查到了叶子节点，只查到了数据对应存放的内存地址，还需要通过这个地址再去获取具体的数据。所以肯定多读了一次io。

索引基本知识

索引优点

大大减少了服务器需要扫描的数据量
帮助服务器避免排序和临时表
将随机io变成顺序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

聚簇索引与非聚簇索引

聚簇索引
不是单独的索引类型，而是一种数据存储方式，指的是数据行跟相邻的键值紧凑的存储在一起
- 优点
1. 可以把相关数据保存在一起
2. 数据访问更快，因为索引和数据保存在同一个树中
3. 使用覆盖索引扫描的查询可以直接使用页节点中的主键值
- 缺点
1. 聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势
2. 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式
3. 更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置
4. 基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题
5. 聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候
非聚簇索引
数据文件跟索引文件分开存放

覆盖索引

如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引
不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值
不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，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;

posted @ 2022-11-25 15:18 aBiu-- 阅读(36) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

aBiu