MYSQL索引介绍（下）

此篇深度解析索引 为承接上篇  有理解索引这块知识点的可以结合 上 下 俩部分 充分理解索引的概念和如何使用

目录

1.5SQL性能分析

1.5.1sql执行频率

实例：

1.5.2慢查询日志

1.5.3 profile 详情         

1.5.3explain执行计划

1.6索引使用

1.6.1验证索引效率

1.6.2最左前缀法则

1.6.3索引列操作

1.6.4or连接的条件 与数据分布影响

1.6.5sql提示

1.6.6覆盖索引

思考题：

1.6.7前缀索引

1.7索引设计原则

---

1.5SQL性能分析

我们再进行优化的时候 得进行判定 而sql的执行频率就是一个“判点”。

1.5.1sql执行频率

通过如下指令 可以查看 增删改的访问频次；

insert，updata，delete，selete访问频次：

show global status like 'com___';

实例：

show global status like'com_______';//七个下划线；

下图为所呈现的各个的执行频次：

我们可以再此刻进行一次select查询语句 

再进行 查询执行频率 show... 就可以明显的看到 对应的select的次数+1 ；

从而我们想，整个的进行是删除多还是查询多 来进行对应的优化分析操作

1.5.2慢查询日志

定位哪个操作语句'慢'，从而方便我们程序员进行优化操作。

（默认没有开启） 开启：修改mysql的配置文件（/etc/my.cnf）：slow_query_log=1;

                                                                                                       long_query_time=2;

注意：修改完需要重启进行使用

实例：select count（*）from tb_sku；//查看后续反应时间 ，如果大于俩秒则是慢查询。

1.5.3 profile 详情         

通过show profiles 可以再做sql优化的时候帮助我们了解时间耗费在哪里。

操作：

select @@have_profiling;

注：默认关闭  得自己开启 在finalshell 输入：set profiling =1；//开启 

      show profiles; 展示全部的耗费时间，从而进行准确的数据库优化。

可以明显发现 通过id 比 通过name 时间明显少。

1.5.3explain执行计划

可以在任意段前加上explain

eg： explain select*from tb where id=1；

explain表中 id：操作表的顺序。

                   select_type:表示select的类型

                    type：访问的连接类型，性能从好到差：null，system，const，eq_ref,ref,range,index,all. (实际是不可能到null）

                    key：实际用到的索引 ，如果为null则没有使用索引。

                   等... 大家可以自行了解。

---

1.6索引使用

1.6.1验证索引效率

我们通常会在没有建立索引之前来查看sql的耗时：

select*from tb where  id=2；

针对字段创建索引：create index idx_sk_id on tb_sk(id); //时间有可能很长

再次执行之上的sql 来进行比较 有没有减少时间提高效率。

1.6.2最左前缀法则

如果索引了多列，要遵守最左前缀法则。

必须包含索引最左边的这个列 ，否则其他的查询结果都是null；

如果索引都用了 则不影响；因为最左的索引包含在内查询；

1.6.3索引列操作

不要在索引列上进行运算操作，否则索引列将失效。

字符串不加引号：字符串不加引号，索引将失效。

模糊查询：尾部模糊，索引不会失效，如果头部模糊，索引将失效。

eg：select *from tb_user where pro like='软件&'  key值将执行索引

反之头部模糊则不执行索引。

1.6.4or连接的条件 与数据分布影响

1：一个有索引一个没有索引 将不会执行索引 得所查询的俩个都有索引才会执行。
2：当所查询的iphone 的数据有一半都满足，则mysql评估使用索引比全表慢，则不使用索引。

1.6.5sql提示

sql提示是优化数据库的一个重要手段，简单来说，就是在sql语句中加入一些人为的提示来达到优化操作的目的

use index:告诉数据库你使用哪个索引

ignore index:告诉数据库你不要用哪个索引

force index:告诉数据库你必须使用哪个索引

1.6.6覆盖索引

尽量使用覆盖索引（查询使用了索引，并且需要返回的列，在该索引中已全部能够找到）

思考题：

一张表，有四个字段（id，username，password，status）由于数据量大，需要对以下SQL语句进行优化，该如何进行才是最优方案：

select ,id ,usernae, password from table where username=‘ljl’；

最佳方案：针对username 和 password 建立联合索引 ，这样不需要进行回表查询 效率最好。

1.6.7前缀索引

将字符串一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率。

语法：create index idx_xxx on table_name(column(n));

前缀长度：根据索引的选择性来决定，选择性简单来说就是不重复的索引值，索引选择性越高则查询效率越高，唯一的索引选择性是1，这是最好的索引选择性，性能也是最好的。

eg：create index idx_email_5 on tb_user(email(5));

1.6.8单列索引与联合索引

单列索引：一个索引只包含单个列

联合索引：一个索引包含了多个列

联合索引情况：create unique index_phone_name on tb_user(phone,name);  

在实际情况下，尽量使用联合索引，避免回表查询概率高。

---

1.7索引设计原则

针对数据量大，查询频率大的表；

针对常用作为查询条件，排序，分组操作的字段建立索引；

尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用效率越高；

字段的长度较长，应建立前缀索引；

尽量使用联合索引，减少单列索引，节省存储空间，避免回表；

要控制索引数量，维护索引的代价也越高，会影响增删改的效率；