Mysql研磨之设计索引原则

1、搜索的索引列:最适合索引的列是出现在where子句中的列,或链接子句中指定的列,而不是出现在select关键词后的选择列表中的列

2、使用唯一索引:考虑列中值的分布。索引的列基础越大,索引的效果越好。列如记录性别的列,不管搜索那个性别,都会得出大约一般的行,因此对此列索引没有太大的作用

3、使用短索引:如果对字符串列进行索引,应该制定一个前缀长度,只要有可能就尽量这样做。例如,有一个CHAR(200)列,如果在前10个或者20个字符进行索引能够节省大量索引空间,也可能会使查询更快。较小的索引涉及的磁盘IO较小,较短的值比较起来更快。更重要的是,对于较短的键值,索引高速缓存中能够容纳更多的键值,因此MySQL也可以在内存中容纳更多的值。这样就增加了找到索引行而不用读取索引中较多块的可能性。

4、利用最左前缀。创建一个n列的索引时,实际是创建了MySQL可利用的n个索引。多列索引可起几个索引的作用,因为可以利用索引中最左边的列集来匹配行。这样的列集成为最左前缀

5、不要过度索引。不要以为索引"越多越好",什么东西都用索引是错误的。每个额外的索引都要占用额外的磁盘空间,并降低写操作的性能。在修改表的内容时,索引必定进行更新,有时可能需要重构,因此,索引越多,所花的时间越长。如果一个索引很少使用或从不使用,那也会不必要的减缓表的修改速度。此外,MySQL在生成一个执行计划时,需要考虑各个索引,这也要花费时间。创建多余的索引给查询优化带来了更多的工作。索引太多也可能会使MySQL选择不到所要使用的最好索引。只保持所需的索引有利于查询优化

6、对于InnoDB存储引擎的表,记录默认会按照一定的顺序保存,如果有明确定义的主键,则会按照主键顺序保存。如果没有主键,但有唯一索引,那么就会按照唯一索引的顺序保存。如果既没有主键又没有唯一索引,那么表中会自动生成一个内部列,按照这个列的顺序保存。按照主键或者内部列的顺序进行访问的速度是最快的,索引InnoDB表尽量自己指定主键,当表中同时有几列都是唯一的,都可以作为主键的时候,要选择最常最为访问条件的列作为主键,提高查询的效率。另外,还需要注意,InnoDB表的普通索引都会保存主键的键值,所以主键要尽可能选择较短的数据类型,可以有效地减少索引的磁盘占用,提高索引的缓存效果

  Hash 索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree索引

1)Hash索引仅仅能满足"=","IN"和"<=>"查询,不能使用范围查询。

  由于 Hash 索引比较的是进行 Hash 运算之后的 Hash值,所以它只能用于等值的过滤,不能用于基于范围的过滤,因为经过相应的 Hash算法处理之后的 Hash 值的大小关系,并不能保证和Hash运算前完全一样。

2)Hash 索引无法被用来避免数据的排序操作。
  由于 Hash 索引中存放的是经过 Hash 计算之后的 Hash值,而且Hash值的大小关系并不一定和 Hash运算前的键值完全一样,所以数据库无法利用索引的数据来避免任何排序运算;

3)Hash索引不能利用部分索引键查询。
  对于组合索引,Hash 索引在计算 Hash 值的时候是组合索引键合并后再一起计算 Hash 值,而不是单独计算 Hash值,所以通过组合索引的前面一个或几个索引键进行查询的时候,Hash 索引也无法被利用。

4)Hash索引在任何时候都不能避免表扫描。
  前面已经知道,Hash 索引是将索引键通过 Hash 运算之后,将 Hash运算结果的 Hash值和所对应的行指针信息存放于一个 Hash 表中,由于不同索引键存在相同 Hash 值,所以即使取满足某个 Hash 键值的数据的记录条数,也无法从 Hash索引中直接完成查询,还是要通过访问表中的实际数据进行相应的比较,并得到相应的结果。

5)Hash索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高

  对于选择性比较低的索引键,如果创建 Hash 索引,那么将会存在大量记录指针信息存于同一个 Hash 值相关联。这样要定位某一条记录时就会非常麻烦,会浪费多次表数据的访问,而造成整体性能

原文地址:https://www.cnblogs.com/prayers/p/9001446.html