MySQL基础索引优化流程

MySQL索引简介

一种优化查询的数据结构，比如Mysql中的索引是用B+树实现的，而B+树就是一种数据结构，可以优化查询速度，可以利用索引快速查找数据，所以能优化查询。以文件的方式存储到磁盘。

b+树优势：b+树高度恒定（可以控制在3到5层），即渐进复杂的恒定，意味着检索是只需要进行几步读取即可。

b+树和b树的比较

1.BTree每个节点都可以存储数据，而B+Tree只有叶子节点才存储数据

2.B+Tree在mysql的实现时还做了定制，可以看到相邻的叶子节点间加了链式的关联的。意味着比如id>1检索，找到1后可以通过链式关联快速继续往下查找

mysql两种数据结构如何设计索引

MyISAM：索引文件数据文件分开存在，检索是先判断是否有索引，有则先到索引文件找到对于数据的逻辑地址，再去数据文件检索对应数据

InnoDB:数据就是一颗B+Tree（也可以理解为索引文件和数据文件在一起）。默认会以主键来创建一个索引，如果创建表时没有指定主键，InnoDB会为你指定一列不重复数据的列作为主键，如果找不到这样的列，那么InnoDB会给你生成一列作为主键（相当于Mongodb 中的 objectId策略）

影响因素

那么mysql数据库如何使用这些索引的，首先mysql会将索引加载到内存中（对于innodb引擎，我们可以认为也会加载数据），而这个能加载多少是由：innodb_buffer_pool_size决定，因此原则上这个值越大越好，但也不能大到超过机器内存。那么被加载的数据会已page形式存放到缓存池中，默认一个page为16k。系统利用LRU算法将缓存池中的数据进行淘汰，所以我们要十分注意innodb_buffer_pool_size的值，我们可以通过show status like "Innodb_buffer_pool_%";查看InnoDB的Buffer Pool情况，其中包括索引命中率，例如：

总共有8191 个page， 有7303 个是Free 状态， 有788个page 有数据，read 请求31569次，其中有710次请求使用物理磁盘获取

InnoDB Buffer Pool 的Read 命中率大概： （31569-710)/ 31569 * 100% = 97.75%，如果我们命中率低于了95%表示我们数据库索引需要进行优化，因为存在大量的IO读写工作。

其中我们十分需要注意数据表和innodb_buffer_pool_size的大小，因为当我们加载数据大于该值后，数据性能会急剧下降。

其中：

Innodb_buffer_pool_pages_data：InnoDB缓冲池中包含数据的页数。 该数字包括脏页面和干净页面。 使用压缩表时，报告的Innodb_buffer_pool_pages_data值可能大于Innodb_buffer_pool_pages_total（Bug＃59550）。

Innodb_buffer_pool_pages_dirty：显示在内存中修改但尚未写入数据文件的InnoDB缓冲池数据页的数量（脏页刷新）。

Innodb_buffer_pool_pages_flushed：表示从InnoDB缓冲池中刷新脏页的请求数。

Innodb_buffer_pool_pages_free：显示InnoDB缓冲池中的空闲页面

Innodb_buffer_pool_pages_misc：InnoDB缓冲池中的页面数量很多，因为它们已被分配用于管理开销，例如行锁或自适应哈希索引。此值也可以计算为Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free - Innodb_buffer_pool_pages_data。

Innodb_buffer_pool_pages_total：InnoDB缓冲池的总大小，以page为单位。

innodb_buffer_pool_reads：表示InnoDB缓冲池无法满足的请求数。需要从磁盘中读取。

innodb_buffer_pool_read_requests：它表示从内存中逻辑读取的请求数。

innodb_buffer_pool_wait_free：通常，对InnoDB缓冲池的写入发生在后台。 当InnoDB需要读取或创建页面并且没有可用的干净页面时，InnoDB首先刷新一些脏页并等待该操作完成。 此计数器计算这些等待的实例。 如果已正确设置innodb_buffer_pool_size，则此值应该很小。如果大于0，则表示InnoDb缓冲池太小。

innodb_buffer_pool_write_request：表示对缓冲池执行的写入次数。

索引优化

1.语句判断分析

基于sql判断是否需要索引优化，我们可以在sql语句前加Explain来判断当前语句，示例：

EXPLAIN SELECT * FROM country_hotpoint_scene c WHERE c.cluster_type = "countryHotpoint" AND c.data_version = 1 AND c.cluster_code = "001" AND c.task_id != "1776630" AND ( c.cr_time BETWEEN "2020-04-30 00:00:00" AND "2020-04-30 23:59:59" )

通过type我们可以看到，现在进行的是全表检索。这时我们就可以考虑索引优化了

注：explain相关可以参考：https://www.cnblogs.com/tufujie/p/9413852.html

2.辨识度判断

我们要明白，索引选择性约稿效率有高。对于内容比较长的字段，我们没有必要保存完整的内容到索引当中，所以我们可以使用前缀索引即可（注意，前缀索引要求前面的辨识度非常高，如果辨识度在长度为一半时还达不到0.846就没必要做这个了）。但具体截取多少呢，我们利用：

SELECT COUNT(DISTINCT last_name)/COUNT(*)FROM people;进行计算，一般来讲0.846即可。同样的，对于组合索引，顺序也是根据选择性来，例如：

3.索引基本概念

1、需要加索引的字段，要在where条件中

2、数据量少的字段不需要加索引（即辨识度）

3、如果where条件中是OR关系，加索引不起作用

4、符合最左原则

例子：

联合索引（a,b,c）使用a或者a或者a、b或a、b、c这3种可以进行查找，不支持b、c进行查找

使用联合索引（a,b,c）。其中这些条件可以可以乱序，因为mysql的sql优化器会优化这些代码