MySQL for OPS 03：索引和执行计划

写在前面的话

啥是索引？以一本书为例，如果想要找到某一指定章节的某一小节，书薄还好，如果书厚，可能就会找的头皮发麻。于是便出现了目录，让用户更容易查找到自己所需要的东西。索引就类似一张表的目录。其存在的意义就是优化查询速度，所以在学习的时候，只要一直记住这个类比，就相对更容易理解一些。

关于索引

在索引中，常见的算法有：B 树，Hash，R 树，Full text，GIS 等。只需要记两三个即可。

其中最重要的就是 B 树索引，可再度分为：B- 树，B+ 树（在 > < like 等查找中性能更优），B* 树

目前最多的就是 B+ 树，其结构可类比为树的：根（Root），枝（Internal），叶（Leaf）

树状结构如图（图片来自互联网）：

在功能上面，索引可分为：辅助索引和聚集索引

辅助索引创建 B 树过程：

当用户执行创建索引操作：alter table t1 add index idx(id);

1. 提取索引列（id 列）的值，进行排序。

2. 向叶子节点申请数据页（16K），然后将排序后的值存储到叶子节点的数据页中，并和真实数据进行关联。

3. 向枝节点和根节点申请数据页，将下层中单页最小值存储进去，如此类推。

聚集索引创建 B 树过程：

聚集索引创建的前提是列为主键或者唯一键，一般为主键，如 ID 字段。

一旦表中有主键列，那么在数据写入的时候就会按照主键的顺序写到磁盘的数据页中。

聚集索引叶节点直接就是真实数据页，减少了 B 树层级。

两者的区别：

聚集索引只能一个，要求非空唯一，一般是主键。辅助索引可以配置多个。

聚集索引叶子节点直接就是真实数据页，辅助索引则是抽离出来排序后的数据。

辅助索引分类：

1. 普通的单列索引。

2. 联合索引（多列索引），用多个列建立一个索引，如：select * from t1 where a=xx and b=xx and c=xx; 这种查询。

3. 唯一索引（unique index）：索引列的值都是唯一。

索引树高度影响因素：

1. 数据行数影响，解决办法：分库分表，分布式

2. 索引列值过长，解决办法：前缀索引

3. 数据类型：变长字符串使用了 char，解决办法：变长使用 varchar

管理索引

查看表的索引情况：

show index from city;
-- 或者
desc city;

结果：

其中：PRI 是主键索引（聚集索引），UNI 是唯一索引（辅助索引），MUL 是辅助索引。

1. 创建普通索引：

alter table city add index idx_name(name);

此时查看创建情况：

注意：同一列可以创建多个索引，但是没意义。同一个表中索引名字必须唯一。

2. 删除索引：

-- 创建一个测试索引
alter table city add index idx_name1(name);

-- 删除测试索引
alter table city drop index idx_name1;

3. 创建多列联合索引：

alter table city add index idx_d_p(District,Population);

此时查看：

注意：索引列的顺序可能会影响 SQL 最终是否会走该索引。

4. 创建前缀索引：

alter table city add index idx_di(District(5));

注意：前缀索引必须是字符串，不能是数字：

5. 创建唯一索引：

alter table city add unique index idx_uni_id(id);

查看：

查看某列的重复情况以参考是否适合做索引列：

select name,count(id) from city group by name having count(id)>1 order by count(id) desc;

查看重复次数：

压力测试：

mysqlslap --defaults-file=/etc/my.cnf --concurrency=100 --iterations=1 --create-schema='库名' --query="select * from 库名.表名 where 字段名='值'" engine=innodb --number-of-queries=2000 -uroot -p -verbose

100 个并发查询，一共查询 2000 次，没索引 100 万数据测试耗时 700s。加索引后为 0.1 秒，性能提升恐怖。

关于执行计划

执行计划的作用在于帮助分析 SQL 是否走索引以及是否走正确的的索引，进而优化业务逻辑。

以 world 库为例，先删除之前 city 表创建的索引：

查看表索引：

看看数据库优化器最终选择的执行计划：

desc select * from city where Name="Shanghai";

只需在执行的 SQL 前加 desc：

其中重要字段的含义：

possible_keys：可能会用到的索引

key：真正使用到的索引

type：索引类型

Extra：额外信息

type 字段详解：（性能逐级提升）

1. ALL：全表扫描，不走索引

a. 查询没有索引的 name 字段：

select * from city where Name="Shanghai";

b. 查询语句中辅助索引使用到：<>，not in，like '%xxx'

desc select * from city where countrycode <> "CHN";
desc select * from city where countrycode not in ("CHN","USA");
desc select * from city where countrycode like "%CH%";

如图：

但在聚集索引字段使用则会走索引，如：

desc select * from city where id <> 100;

如图：

2. INDEX：全索引扫描

a. 查询需要获取整个索引树时：

desc select countrycode from city;

如图：

b. 联合索引中，任何一个非最左列作为查询条件：

假如索引 idx_a_b_c(a,b,c) 其实相当于建立了索引：a，ab，abc。此时 a 就是最左列，此时：

select * from t1 where b=xxx;

3. RANGE：索引范围扫描

辅助索引：<，>，>=，<=，like，in，or

主键：<>，not in

注意：前两种能享受到 B+ 树的优势，第三种 in 方法不会，为了优化可以写成：

desc select * from city where countrycode="CHN" union all select * from city where countrycode="USA";

结果：

4. ref：非唯一性索引，等值查询

desc select * from city where countrycode="CHN";

结果：

5. eq_ref：多表连接时，连接条件使用唯一索引

desc select a.name,b.name from city as a join country as b on a.countrycode=b.code where a.population<100;

结果：

6. const：唯一索引等值查询

desc select * from city where id=10;

结果：

Extra 字段说明：

desc select * from city where countrycode="CHN" order by population;

在使用排序的时候会发现，在 extra 字段出现：filesort （文件排序）

说明在使用 order by 的时是没有走索引的，之前说过，辅助索引会将索引列的值抽离出来进行排序。

但 where 条件用了索引，由此得出：在多个条件的时候，优化器只会选择其中一个索引。

解决办法：将多个条件中字段创建联合索引：

alter table city add index idx_c_p(countrycode,population);
desc select * from city where countrycode="CHN" order by population;

再度查看：

同理在 group by，distinct 中也一样。

联合索引中的特殊情况：

1. select * from t1 where a=xxx and b=xxx; 这种情况下，创建索引：

alter table t1 add index idx_a_b(a,b); 和 alter table t1 add index idx_b_a(b,a); 效果一样。

where 会自动调整顺序使其满足索引需求，但创建时应将唯一值更多放在前面。

2. 如果 where 中出现不等值查询：select * from t1 where k1 > 100 and k2="aaa";

创建索引应该：alter table t1 add index idx_2_1(k2,k1);

并将语句 k2="aaa" 放前面，否则 > 在前会卡住索引，导致后面条件不走索引。

3. 如果语句中存在多个子句，则需要按照执行顺序建立索引。

线上数据库卡顿解决思路：

1. show processlist; 或者 show full processlist; 查看问题 SQL，如果暂时无法解决，可先 kill 掉。

2. 使用 desc 或者 explain 分析 SQL 走索引的情况，如果没走索引，通过分析后建立索引。

特定的时间段慢的解决思路：

可以通过后面的 slowlog 找到慢 SQL，分析语句走索引情况和耗时情况，进行修改。

建立索引的原则

1. 建表时一定要有主键，一般采用无关列。

2. 尽量选择唯一性索引，如果非要使用重复值较多的，可将表逻辑拆分，也可将此列和其他列做联合索引。

3. 为经常需要 where / order by / group by / join on 等操作的字段建立索引。

4. 索引字段很长，尽量采用前缀索引。

5. 索引不是越多越好，索引越多，越占空间，修改表越慢，可使用 percona-toolkit 的 pt-duplicate-key-checker 进行索引清理。

6. 大表加索引需避开业务高峰期。

7. 尽量避免在经常更新的列上面加索引。

不走索引的情况

1. 没有查询条件或者条件未建立索引。

2. 查询结果集是原表中大部分数据，数据超过 25%，优化器会觉得没必要走索引。可使用 limit 或存 redis 解决。

3. 索引失效，导致数据不真实。如果表经常修改，容易导致索引失效，需要删除重建解决。

4. 查询条件使用函数在索引列上面，或则对索引列进行 + - * / 计算等，如：select * from t1 where id-1=9;

5. 隐式转换导致索引失效，如号码一般是 varchar 保存全数字，通过 select * from t1 where phone=120; 或 where phone='120'; 结果一致，但前者不走索引。

6. <>，not in 是不走索引的，> < in 这些也有可能不走，后者尽量使用 union all 优化。

7. like 中 % 在前面不走索引，如 like "%HN"。

小结

本章节索引和执行计划简直是 MySQL 优化中重中之重，当然在数据库小的时候还不明显，当数据量大起来以后，质的飞跃。