Mysql调优（四）（2）索引

目录

哈希索引

哈希索引的限制

组合索引

聚簇索引和非聚簇索引

覆盖索引        

索引监控

---

首先给各位真挚道个歉，很久没有更新了。有些是不是以为我已经放弃更新了。肯定不会的，这段时间虽然没有更新，但是自己的学习研究都是没有放弃的。许多小伙伴也是。希望在这或者哪点又不周的，可以海涵指点。谢谢

 

哈希索引

基于哈希表的实现，只有精确匹配所有列的查询才有效

在mysql中，只有memory的存储引擎显示支持哈希索引

哈希索引自身只需存储对应的hash值，所以索引的结构十分紧凑，这让哈希索引查找的速度非常快

哈希索引的限制

1. 哈希索引只包含哈希值和行指针，而不存储字段值，索引不能使用索引中的值来避免读取行
2. 哈希索引数据不是按照索引值顺序储存的，所以无法进行排序。
3. 哈希索引不支持部分列匹配查找，哈希索引是使用索引列的全部内容来计算哈希值
4. 哈希索引支持等值比较查询，也不支持任何范围查询
5. 访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候,存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行。
6. 哈希冲突比较多的话，维护的代价也会很高。

也可以使用crc32做哈希

select id from url where url ="" and url crc = CRC32("")

组合索引

当包含多个列作为索引，需要注意的是正确的顺序依赖于该索引的查询，同时需要考虑如何更好的满足排序的分组的需要。比如最左匹配

聚簇索引和非聚簇索引

Innodb是聚簇索引 不是单独的索引类型，而是一种数据存储方式，指的是数据行跟相邻的键值紧凑的存储在一起

• 优点
  • 可以把相关数据保存在一起
  • 数据访问更快，因为索引和数据保存在同一个树中
  • 使用覆盖索引扫描的查询可以直接使用叶节点中的主键值
• 缺点
  • 聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势
  • 插入速度严重依赖于插入顺序，按照主键的顺序插入时最快的方式
  • 更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置
  • 基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临分裂的问题
  • 聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候

myisam 是非聚簇索引 数据文件跟索引文件分开存放

覆盖索引        

如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引。是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值。不同的存储引擎实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引。

优势

1. 索引条目通常远小于数据行大小，如果只需要读取索引，那么mysql就会极大的较少数据访问量。
2. 因为索引是按照列值顺序存储的，所以对于io密集型的范围查询回比随机从磁盘读取每一行数据的io要少的多
3. 一些存储引擎如Myisam在内存中缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用，这可能回导致严重的性能问题。
4. 由于innodb的聚簇索引，覆盖索引对innodb表特别有用

细节

1. 当使用索引列进行查询的时候尽量不要使用表达式，把计算放到业务层而不是数据层
2. 尽量使用主键查询，而不是其他索引，因此主键查询不会触发回表查询
3. 使用前缀索引
4. 使用索引扫描来排序

Mysql有两种方式可以生成有效的结果：通过排序操作或者按索引顺序扫描，如果explain出来的type列的值为index,则说明mysql使用的索引扫描来做排序。

扫描索引本身是很快的，因为只需要从一条索引记录移动到紧接着的下一跳记录。但如果索引不能覆盖查询所需的全部列，那么就不得不 每扫描一条索引记录就得回表查询一次对应的行，这基本都是随机io，因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢。

mysql可以使用同一个索引即满足排序，又用于查找行，如果可能的话，设计索引时应该尽可能地同时满足这两种任务。

        5. union all,in,or 都能够使用索引，但是推荐使用in

这三种本质是一样的。但是哪种效率是不一样的。union all 和 union 相比 就用union all。union 本身带着一个distinct,distinct 本就降低效率，所以推荐使用union all;为什么推荐in，是因为union all 是两个步骤 是两次查询 所以时间是比较慢一点的。如果超过了1000的数量就不推荐使用in。exists 虽然很快 但是不能查找子查询的字段。

        6.范围列可以用到索引

范围条件是：,>=,between

范维列可以用到索引，但是范围列后的列无法用到索引，索引最多用于一个范维

        7.强制类型转换会全表扫描

        8.更新十分频繁，数据区分度不高的字段上不宜建立索引

• 1. 更新会变成B+树，更新频繁的字段建立索引会大大降低数据库性能
  2. 类似于性别这类区分不大的属性，建立索引是没有意义的，不能有效的过滤数据
  3. 一般区分度在80%以上的时候就可以建立索引，区分度可以使用count(distinct(列名))/count(*)来计算
• 9.创建索引的列，不允许为null，可能会得到不符合预期的结果
• 10.当需要进行表连接的时候，最好不要超过三张表，因为需要join的字段，数据类型必须一致。
• 11.如果明确知道只有一条结果返回，limit 1 能够提高效率

ps:limit 不是分页 而是限制输出

     12.单表索引建议控制在5个以内

     13.单索引字段不允许超过5个

     14.创建索引的时候应该避免以下错误概念

                a.索引越多越好

                b. 过早优化，在不了解系统的情况下进行优化

一般而言，一张表只有很少的字段会使用到B+索引。因为维护索引也是需要一定的资源。加的索引的字段一般都是经验而言，如果非要一个效益最大化的话，可以根据Cardinality来。

去重之后的唯一值就是基数 的近似值就是Cardinality，基数越小 索引的效率也就会更加的高效。

HyperLogLog 算法

HyperLogLog是Redis的高级数据结构，是统计基数的利器。HyperLogLog实际上不会存储每个元素的值，它使用的是概率算法，通过存储元素的hash值的第一个1的位置，来计算元素数量。

索引监控

show status like 'Handler_read%'

1. Handler_read_first 读取索引第一个条目的次数
2. Handler_read_key 通过index获取数据的次数
3. Handler_read_last 读取索引最后一个条目的次数
4. Handler_read_next 通过索引读取下一条数据的次数
5. Handler_read_prev 通过索引读取上一条数据的次数
6. Handler_read_rnd 从固定位置读取数据的次数
7. Handler_read_rnd_next 从位置节点读取下一条数据的次数