1.EXPLAIN执行解释器
explain SELECT * from t1 where id=1;
图片.png
- id: 标识select所属行
- select_type:SIMPLE代表不包含子查询和UNION操作，如果有任何复杂的子部分，则最外层的标记为PRIMARY.
SUBQUERY:包含在select列表中的的子查询的select(就是不在from语句中的子查询)。
DERIVED：表示包含在from子句的子查询的select。
UNION : 执行关系代数的并操作
UNION RESULT:表示从UNION操作的临时表检索结果的select,但是他实际是不存在的所以id为null. - table: 表示检索的表
- type:
- all : 全表扫描
- index :和全表扫描一样，只是使用的是索引次序而不是行。
- range :带有限制的索引扫描
- ref : 索引查找，返回符合条件的行可能有多行。只有当使用了非唯一性索引或者唯一性索引的非唯一前缀才会发生。
- eq_ref ： 索引查找，只返回一行，使用主键或者唯一索引查找才能看见。
- const,system : 常量，一般只查寻一行会显示
- null : 在优化阶段分解语句，在执行阶段甚至不用访问表或者索引
- possible_keys:可能用到的索引
-keys : 用到的索引 - key_len :使用索引的字节数
- ref : 索引中查找所用的列或者常量
- rows :查询的行数
- extra : 额外的信息
2.Mysql中的索引
在Mysql中，索引是在存储引擎层而不是服务器层实现的，不同的存储引擎的索引的工作方式也不一样。而我们主要关心InnoDB的索引方式。
2.1B树索引
Mysql默认的InnoDB支持B树索引，采用的是B+树的实现方式，通过上篇文章的分析我们知道了B+树索引适用于全建值，键值范围，键值前缀查找。
CREATE TABLE people (
sur_name VARCHAR (30) NOT NULL,
name VARCHAR (30) NOT NULL,
dob date NOT NULL,
sex enum ('w', 'm'),
KEY (sur_name, NAME, dob)
);
insert into people values('张','三',1991-01-01,'m');
insert into people values('李','强',1995-07-01,'m');
insert into people values('王','翠花',1995-02-10,'w');
insert into people values('张','铁牛',1994-05-02,'m');
insert into people values('郭','小花',1995-04-01,'w');
insert into people VALUES ('欧阳','狗子',1999-01-30,'m');
图片.png
- 全值匹配
全值匹配是指和索引列中的所有列进行匹配。
explain select * from people where sur_name ='张' and name='三' and dob=1991-01-01;
图片.png
- 匹配最左前缀
即只使用索引的第一列
explain select * from people where sur_name ='张';
图片.png
-匹配列前缀
匹配某一列索引的值的开头部分，但是只能是索引的第一列。
explain select * from people where sur_name ='欧%';
图片.png
- 精确匹配某一列范围匹配另一列
索引第一列必须精确匹配
EXPLAIN select * from people where sur_name='王' and name='翠%';
图片.png
2.2B树索引失效
- 如果不是按照索引的最左列开始查找则，无法使用索引。
例如上述，索引不能查找名为 '三' ，也不能查找到生日为' 1991-01-01'的人，因为这两列都不最左数据列。同样也不能查找到姓氏以某个字结尾的人。
EXPLAIN select * from people where name='三';
图片.png
- 不能跳过索引的某一列，否则索引只能使用最左列索引
例如不能使用索引查询姓张在1999-01-01出生的人
EXPLAIN select * from people where sur_name ='张' and dob =1991-01-01;
图片.png
- 如果查询中有某个列的范围查询，则其右边的所有列都无法使用索引。
2.3hash索引
create table testhash(
fname varchar(30) not null,
lname varchar(30) not null,
key using hash(fname)
) engine = memory;
insert into testhash values ('admin1','tom1');
insert into testhash values ('admin2','tom2');
insert into testhash values ('admin3','tom3');
insert into testhash values ('admin4','tom4');
insert into testhash values ('admin5','tom5');
在mysql中memory引擎是唯一支持显式指定hash索引的。InnoDB创建的是“自适应哈希索引”在B树的基础上建立一个伪哈希索引。在查询时需要在where中手动指定哈希函数。
图片.png
2.3.1hash索引的原理
存储引擎会对所有的索引列计算一个hash code ,哈希码是一个比较小的值，并且不同的键值计算出来的哈希码也不一样，哈希索引将所有的hash码存储在索引中，同时在hsah表中保存指向每个数据行的指针。
2.3.2hash索引的限制
- 哈希索引只包含哈希值和行指针，而不存储数据行，所以不能避免读取数据行。不过内存的行的访问速度非常快。
- 哈希索引并不是按照索引值排序的，再哈希索引中哈希值是有序的而数据行不是，所以无法用于排序。
-哈希索引不支持索引列部分匹配查询，因为哈希索引是根具索引列内容计算哈希值的，例如，在数据列(A,B)上建立哈希索引，如果之查询数据列A无法使用。
-哈希索引只支持等值比较查询，不支持任何的范围查询。
2.3.3hash索引的实际运用
例如，我们要根据很长的url进行查询，如果用url本身做索引，B树的存储内容就会很大。我们可以新增一个url_crc列，使用CRC3做哈希，优化查询。但是这样做的一个缺陷就是需要手动维护hash code,可以手动维护也可以用触发器实现。
create table pseudohash(
id int UNSIGNED not null auto_increment,
url varchar(255) not null,
url_crc int UNSIGNED not null default 0,
PRIMARY key (id)
);
create trigger pseudohash_crc_ins before insert on pseudohash for each row begin
set new.url_crc=CRC32(new.url);
end;
create trigger pseudohash_crc_ins before insert on pseudohash for each row begin
set new.url_crc=CRC32(new.url);
end;
select * from pseudohash where url_crc=CRC32('http://www.baidu.com');
但是有一个问题需要考虑的是哈希冲突，当数据量很大的时候CRC32会出现很多重复的哈希值，所以我们可以自己定义一个函数，例如，截取MD5()函数的一部分作为哈希函数。而且在查询的时候一定要加常量值.
select * from pseudohash where url_crc=CRC32('http://www.baidu.com')
and url='http://www.baidu.com';
总结
索引可以大大减少服务器扫描的数据量，可以帮助服务器避免排序和临时表，可以将随机IO变为顺序IO。
B-Tree和Hash
- 在mysql中只有memory支持显式的hash索引，其他的引擎是在B-Tree的基础上建立的伪哈希索引。
- 哈希索引不支持范围查询，而B-Tree支持
- 哈希索引在等值查询上占有优势
- B-Tree可以用于分组 和排序操作，而哈希索引不可以
- 哈希索引不支持部分索引匹配查询