Mysql 索引
1 概述
1.1 底层原理
你知道 mysql 底层的索引是依托于什么数据结构所实现的吗？
二叉树？B树？红黑树？
其实了解数据结构的你一定很快就会想到，我们所常见的树结构如果作为索引将会使得树的层级较深，检索速度也就随之降低。
而 B树 是一个多叉路平衡查找树，这种数据结构虽然在二叉树的基础上降低了层级，但是要知道 InnoDB 引擎下每个 Page 仅有 16 KB的空间，如果像 B树 一样，不管是非叶子结点还是叶子结点都会存放数据。这就导致一页中存储的键值减少，指针也就跟着减少，这种情况下，如果要保存大量的数据就必须去增加树的高度，所以性能也就随之降低。
所以最终 Mysql 底层选择了 B+ 树作为索引的数据结构依托。
1.2 索引分类
1.2.1 基本分类
在MySQL数据库，将索引的具体类型主要分为以下几类：主键索引、唯一索引、常规索引、全文索引。
| 分类 | 含义 | 特点 | 关键字 |
|---|---|---|---|
| 主键索引 | 针对表中主键创建 | 默认自动创建，只存在一个 | PRIMARY |
| 唯一索引 | 避免同一个表中某数据列中的值重复 | 可以有多个 | UNIQUE |
| 常规索引 | 快速定位数据 | 可以有多个 | |
| 全文索引 | 用于查找文本中的关键词 | 可以有多个 | FULLTEXT |
1.2.2 聚集索引 二级索引
| 分类 | 含义 | 特点 |
|---|---|---|
| 聚集索引 | 将数据存储与索引放到了一起，索引结构的叶子结点保存了行数据 | 必须有，而且只有一个 |
| 二级索引 | 将数据与索引分开存储，索引结构的叶子结点关联是对应的主键 | 可以存在多个 |
聚集索引选取规则:
-
如果存在主键，主键索引就是聚集索引。
-
如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。
-
如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引。
索引此处就可以引发一定的思考，比如同一张表，where 非主键与 where 主键 ，后者肯定是更快的，因为二级索引会有先查二级索引后回表查询的步骤。
1.3 索引语法
1） 创建索引
CREATE [UNIQUE | FULLTEXT] INDEX index_name ON table_name(index_col_name,...)
2）查看索引
SHOW INDEX FROM table_name;
3）删除索引
DEOP INDEX index_name ON table_name
2 Sql性能分析
2.1 Sql 频率
MySQL 客户端连接成功后，通过 show [session|global] status 命令可以提供服务器状态信息。通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次：
-- session 是查看当前会话 ;
-- global 是查询全局数据 ;
SHOW GLOBAL STATUS LIKE 'Com_______';
结果如图：
通过上述指令，我们可以查看到当前数据库到底是以查询为主，还是以增删改为主，从而为数据库优化提供参考依据。 如果是以增删改为主，我们可以考虑不对其进行索引的优化。 如果是以查询为主，那么就要考虑对数据库的索引进行优化了。
2.2 慢查询日志
慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有
SQL语句的日志。
MySQL的慢查询日志默认没有开启，我们可以查看一下系统变量 slow_query_log。
可以通过以下命令查看：
show variables like 'slow%'
结果如图：
那么如何去开启慢查询日志呢？
一般有俩种方式：
第一：去修改配置文件在 my.cnf 中加入 一下语句
log-slow-queries=dir\filename
long_query_time=n
第二：通过命令直接设置
SET GLOBAL slow_query_log=ON/OFF;
SET GLOBAL long_query_time=n;
当然你一定会遇到下面这个问题。
set global long_query_time=1;为啥无效呢，再查还是原来的10
修改之后，先关闭数据库连接，再重新连接，再次查询就可以看到实际上是修改了的。
之后去 {slow_query_log_file} 下 查看日志即可
结果如图：
！删除慢查询日志
慢查询日志的删除方法与通用日志的删除方法是一样的。可以使用 mysqladmin 命令来删除。也可以使用手工方式来删除。mysqladmin 命令的语法如下：
mysqladmin -uroot -p flush-logs
2.3 profile详情
通过上面对慢查询日志的设置，我们会轻易的发现，它的逻辑是只有超过了 long_query_time 的才会被记录进入日志，那么执行时间只比零界线低一点的却无法记录。
由此演化出了 profile
show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。
通过have_profiling参数，能够看到当前MySQL是否支持profile操作：
select @@have_profiling;
但是默认该设置是关闭的
开闭可以通过如下语句查看：
select @@profiling;
结果如图：
接下来，如果需要使用，则需要通过 set 语句进行设置。
set profiling = 1;
在执行过 sql 查询语句之后，可以用过 命令来查看每一条 sql 的耗时基本情况：
show profiles
结果如图：
衍生命令
- 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
- 查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query query_id;
2.4 EXPLAIN执行计划
EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序。
基本语法：
-- 直接在select语句之前加上关键字 explain / desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;
Explain 执行计划中各个字段的含义:
| 字段 | 含义 |
|---|---|
| id | select查询的序列号，表示查询中执行select子句或者是操作表的顺序(id相同，执行顺序从上到下；id不同，值越大，越先执行) |
| select_type | 表示 SELECT 的类型，常见的取值有 SIMPLE（简单表，即不使用表连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（UNION 中的第二个或者后面的查询语句）、SUBQUERY（SELECT/WHERE之后包含了子查询）等 |
| type | 表示连接类型，性能由好到差的连接类型为NULL、system、const、eq_ref、ref、range、 index、all 。 |
| possible_key | 显示可能应用在这张表上的索引，一个或多个。 |
| key | 实际使用的索引，如果为NULL，则没有使用索引。 |
| key_len | 表示索引中使用的字节数， 该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下， 长度越短越好 。 |
| rows | MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个估计值，可能并不总是准确的 |
| filtered | 表示返回结果的行数占需读取行数的百分比， filtered 的值越大越好。 |
3 索引使用
3.1 最左前缀法则
如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。如果跳跃某一列，索引将会**部分失效(**后面的字段索引失效)。
现在验证一下该原则：
此时表中存在一组三列的联合索引,执行语句
explain select * from tb_user where profession = '国际贸易' and age = 30 and status = '0';
此时三组索引全部触发，长度为 54
为了验证是否会部分失效
explain select * from tb_user where profession = '软件工程' and status = '0';
explain select * from tb_user where profession = '软件工程' and age = 31;
其中前者的索引长度是 47，而后者的索引长度是 49。则证明了索引不连续会造成部分索引失效。
同时我们也可以发现只要联合索引最左边的字段 profession存在，索引就会生效，只不过索引的长度不同。 而且由以上三组测试，我们也可以推测出profession字段索引长度为47、age字段索引长度为2、status字段索引长度为5。
接着继续测试
explain select * from tb_user where age = 31 and status = '0';
上述语句结果如图
此时索引失效。
所以可以得出结论，最左侧 profession 不存在，会造成索引失效。也就是不满足最左前缀法则。
但是值得一提的是下面这个语句：
explain select * from tb_user where age = 31 and status = '0' and profession = '软件工程'；
结果如图：
它的结果竟然是惊人的 54 ，不过这也证明了一个逻辑 最左前缀法则中指的最左边的列，是指在查询时，联合索引的最左边的字段(即是
第一个字段)必须存在，与我们编写SQL时，条件编写的先后顺序无关。
3.1 范围查询
联合索引中，出现范围查询(>,<)，范围查询右侧的列索引失效。
比如：
explain select * from tb_user where profession = '软件工程' and age >= 31 and status = '0';
explain select * from tb_user where profession = '软件工程' and age > 31 and status = '0';
这俩行代码的结果是 前者 索引长度为 54，后者 索引长度为 49，加之之前 status 的索引长度为 5，可以推断出减少等号后，status 的索引出现了失效现象。
所以，在使用范围查询时，要尽量添加 ‘=’；
3.3 索引失效
以下几种情况会造成索引的直接失效，这里就不一一列举了。
- 对索引列进行运算
- 对于字符串类型的索引列，在书写 sql 的时候没有添加 单引号（‘’）
- 对于模糊查询，like后的关键词，正则符需要放于具体字符之后，否则索引会失效，比如（”%abc“）失效，但是（“ABC%”）却不会。
- 用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。(or左右必须都有索引)
另外还有需要特别记忆的一种情况：
MySQL在查询时，会评估使用索引的效率与走全表扫描的效率，如果走全表扫描更快，则放弃索引，走全表扫描。 因为索引是用来索引少量数据的，如果通过索引查询返回大批量的数据，则还不如走全表扫描来的快，此时索引就会失效。
比如：
explain select * from tb_user where phone >= '17799990005';
explain select * from tb_user where phone >= '17799990015';
以上同样的 sql 但执行计划却有很大的差异。
后者结果：
前者结果：
这就是 Mysql 索引失效的原因之一 -------- 数据分布影响。
3.4 Sql提示
现在 为 profession 加入单列索引。
目前的索引情况为：
explain select * from tb_user where profession = '化工';
使用上述sql后的结果如图：
possible_keys 有俩个，是上图中的联合索引和单列索引。但是具体使用的是联合索引。
那么，这种选择的依据来源于哪里呢？？
啊啊啊啊，暂时不知道，或许是Sql优化器的功劳了。。。。
那么如何去选择执行的索引呢？ 可以采用以下语句
1). use index ： 建议MySQL使用哪一个索引完成此次查询（仅仅是建议，mysql内部还会再次进
行评估）。
explain select * from tb_user use index(profession_index) where profession= '化工';
2). ignore index ： 忽略指定的索引。
explain select * from tb_user ignore index(profession_index) where profession= '化工';
3). force index ： 强制使用索引。
explain select * from tb_user force index(profession_index) where profession= '化工';
3.5 覆盖索引
尽量使用覆盖索引，减少select *。 那么什么是覆盖索引呢？ 覆盖索引是指 查询使用了索引，并
且需要返回的列，在该索引中已经全部能够找到 。
简单来说就是查询结果必须在索引列范围内。否则会造成回表查询
使用以下语句进行校验：
explain select * from tb_user where profession = '软件工程' and age = 31 and status = '0' ;
explain select id,profession,age from tb_user where profession = '软件工程' and age = 31 and status = '0' ;
结果如图：
左侧为下语句执行结果。
| Extra | 含义 |
|---|---|
| Using where; Using Index | 查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据 |
| Using index condition | 查找使用了索引，但是需要回表查询数据 |
3.6 前缀索引
当字段类型为字符串（varchar，text，longtext等）时，有时候需要索引很长的字符串，这会让索引变得很大，查询时，浪费大量的磁盘IO， 影响查询效率。此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。
基本语法如下：
create index idx_xxxx on table_name(column(n)) ;
前缀长度的求取：
可以根据索引的选择性来决定，而选择性是指不重复的索引值（基数）和数据表的记录总数的比值，索引选择性越高则查询效率越高， 唯一索引的选择性是1，这是最好的索引选择性，性能也是最好的。
-- 意在判定前几个字符是不重复的
select count(distinct email) / count(*) from tb_user ;
select count(distinct substring(email,1,5)) / count(*) from tb_user ;
前缀索引的查询过程是：
在二级索引比对前缀 --> 回表查询–>再次比对
3.7 索引设计原则
1). 针对于数据量较大，且查询比较频繁的表建立索引。
2). 针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索
引。
3). 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
4). 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
5). 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，
避免回表，提高查询效率。
6). 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增
删改的效率。
7). 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含
NULL值时，它可以更好地确定哪个索引最有效地用于查询。
619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
