Mysql调优之索引优化（四）

一、mysql索引结构B+树原理

B树开始就是n树，不是二叉树

B树的非叶子结点存储了数据，导致层级会很深，每一层又有数据又有索引。

B+树只有叶子结点存储数据，其余都是存储索引，增加了每层存取索引的数量（3层结构就可以支持千万条数据查询）。

二、索引基本知识

索引的优点
- 1、大大减少了服务器需要扫描的数据量
- 2、帮助服务器避免排序和临时表（order by是全排序--比较慢，可以使用索引排序，因为索引已经排好顺序了）
- 3、将随机io变成顺序io（顺序io比随机io快多了）
索引的用处
- 1、快速查找匹配WHERE子句的行
- 2、从consideration中消除行,如果可以在多个索引之间进行选择，mysql通常会使用找到最少行的索引
- 3、如果表具有多列索引，则优化器可以使用索引的任何最左前缀来查找行
- 4、当有表连接的时候，从其他表检索行数据
- 5、查找特定索引列的min或max值（索引有排序，取一头一尾）
- 6、如果排序或分组时在可用索引的最左前缀上完成的，则对表进行排序和分组
- 7、在某些情况下，可以优化查询以检索值而无需查询数据行
索引的分类
- 主键索引
- 唯一索引（数据库默认会给唯一键建索引，而数据库的主键是唯一切非空值）
- 普通索引
- 全文索引（varchar，char，text类型）
- 组合索引
面试技术名词
- 回表
  - （建普通索引的时候，索引的叶子节点存储的不是整行数据，所以查到这部分数据后，如果select *，则回重新用

主键索引的B+树里面查出整行数据，就是回表了）

覆盖索引
- （回表的基础上，不用select*，只查出索引字段对应的id跟索引字段，则可以不用回表，这种操作就叫覆盖索引）
最左匹配
- （针对组合索引时，假如组合索引name跟age，查询中会先匹配name，后匹配age，如果查询条件只有个age，则无法触发该组合

索引，因为会最先匹配左边的）

索引下推
- （针对组合索引，先过滤掉数据再进行索引交集的一种策略（提前在存储引擎层做过滤，而不是在Service层做判断，就是下推的实际意义））

索引采用的数据结构
- 哈希表
- B+树（性能综合来说相对较优解）
索引匹配方式（6种）
- 全值匹配
  - 全值匹配指的是和索引中的所有列进行匹配
    - explain select * from staffs where name = 'July' and age = '23' and pos = 'dev';
- 匹配最左前缀
  - 只匹配前面的几列
    - explain select * from staffs where name = 'July' and age = '23';
    - explain select * from staffs where name = 'July';
- 匹配列前缀
  - 可以匹配某一列的值的开头部分
    - explain select * from staffs where name like 'J%';
    - explain select * from staffs where name like '%y';
- 匹配范围值
  - 可以查找某一个范围的数据
    - explain select * from staffs where name > 'Mary';
- 精确匹配某一列并范围匹配另外一列
  - 可以查询第一列的全部和第二列的部分
    - explain select * from staffs where name = 'July' and age > 25;
- 只访问索引的查询
  - 查询的时候只需要访问索引，不需要访问数据行，本质上就是覆盖索引
    - explain select name,age,pos from staffs where name = 'July' and age = 25 and pos = 'dev';
    - explain select * from staffs where name = 'July' and age = 25 and pos = 'dev';【这个就不是覆盖索引了，因为用了*，会进行回表操作】

三、哈希索引

数据库重启后，memory中的内容会消失，各类行政区

当需要存储大量的URL，并且根据URL进行搜索查找，如果使用B+树，存储的内容就会很大

select id from url where url=""

也可以利用将url使用CRC32（把一个很长的字符串变成一个整数值）做哈希，可以使用以下查询方式：

select id fom url where url="" and url_crc=CRC32("")

此查询性能较高原因是使用体积很小的索引来完成查找

基于哈希表的实现，只有精确匹配索引所有列的查询才有效
- 也就是说不能使用范围查找，否则就不能匹配索引的所有列
在mysql中，只有memory的存储引擎显式支持哈希索引
哈希索引自身只需存储对应的hash值，所以索引的结构十分紧凑，这让哈希索引查找的速度非常快
- 索引本身是数据的一个整数值的取模运算的值
哈希索引的限制
- 1、哈希索引只包含哈希值和行指针，而不存储字段值，索引不能使用索引中的值来避免读取行
  - 所以整体的一个过程（根据哈希值->读取到行指针->最后读取到数据（由于是在memory中运行，所以执行过程非常快））
- 2、哈希索引数据并不是按照索引值顺序存储的，所以无法进行排序（因为取完哈希值之后，排序就不确定了）
- 3、哈希索引不支持部分列匹配查找，哈希索引是使用索引列的全部内容来计算哈希值
- 4、哈希索引支持等值比较查询，也不支持任何范围查询
- 5、访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候，存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行（使用优秀的哈希算法，jdk里面的Hashmap哈希值计算也非常复杂）
- 6、哈希冲突比较多的话，维护的代价也会很高
案例
哈希索引
- 场景
  - 【在我们存储的索引需要占很大空间的时候，就要使用哈希索引，用计算后的hash值作为索引】
  - 当你需要存储一个上百万的常量值的时候，不经常改变，可以使用并且指定engine为memory，但要注意，memory引擎不能持久化，

四、组合索引

组合索引
- 当包含多个列作为索引，需要注意的是正确的顺序依赖于该索引的查询，同时需要考虑如何更好的满足排序和分组的需要
- 案例，建立组合索引a,b,c
  - 不同SQL语句使用索引情况
  - b使用范围查找，就会被忽略了

五、聚簇索引

导致索引频繁更新，效率极其低下）

5、聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候
聚簇索引
- 不是单独的索引类型，而是一种数据存储方式，指的是数据行跟相邻的键值紧凑的存储在一起（innoDB存储引擎B+树）
  - 优点
    - 1、可以把相关数据保存在一起
    - 2、数据访问更快，因为索引和数据保存在同一个树中
    - 3、使用覆盖索引（只查索引的列值）扫描的查询可以直接使用页节点中的主键值
  - 缺点
    - 1、聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势
    - 2、插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式
    - 3、更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置
    - 4、基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂（还可能存在页合并的问题）的问题
      - （所以大数据迁移的时候，最好需要先关闭索引创建，然后迁移数据，最后开启索引创建。否则一边导入数据，一边创建索引

六、非聚簇索引

非聚簇索引（MyISAM存储引擎）
- 数据文件跟索引文件分开存放

七、覆盖索引

1、当发起一个被索引覆盖的查询时，在explain的extra列可以看到using index的信息，此时就使用了覆盖索引

mysql> explain select store_id,film_id from inventory \G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: inventory

partitions: NULL

type: index

possible_keys: NULL

key: idx_store_id_film_id

key_len: 3

ref: NULL

rows: 4581

filtered: 100.00

Extra: Using index（使用了覆盖索引的标志指标）

1row inset, 1warning (0.01sec)

2、在大多数存储引擎中，覆盖索引只能覆盖那些只访问索引中部分列的查询。不过，可以进一步的进行优化，可以使用innodb的二级索引来覆盖查询。

例如：actor使用innodb存储引擎，并在last_name字段又二级索引，虽然该索引的列不包括主键actor_id，但也能够用于对actor_id做覆盖查询

mysql> explain select actor_id,last_name from actor where last_name ='HOPPER'\G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: actor

partitions: NULL

type: ref

possible_keys: idx_actor_last_name

key: idx_actor_last_name

key_len: 137

ref: const

rows: 2

filtered: 100.00

Extra: Using index

1row inset, 1warning (0.00sec)

覆盖索引
- 基本介绍
  - 1、如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引
  - 2、不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值
  - 3、不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引
- 优势
  - 1、索引条目通常远小于数据行大小，如果只需要读取索引，那么mysql就会极大的较少数据访问量
  - 2、因为索引是按照列值顺序存储的，所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多
  - 3、一些存储引擎如MYISAM在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用，这可能会导致严重的性能问题
  - 4、由于INNODB的聚簇索引，覆盖索引对INNODB表的效率提高特别有用
- 案例演示