【MySQL】总结了适合创建索引和不适合创建索引的一些情况

前言：本文可以理解为经验或实践的总结，为什么会有这些索引设计原则还是基于如下的底层原理：

1、InnoDB 记录格式：原理在参考资料列出

2、InnoDB 数据页格式：原理在参考资料列出

3、索引组织表、B+树索引：原理在参考资料列出

4、执行计划：文章近期在写

5、查询优化器的成本：文章近期在写

这些设计原则在了解了相关理论知识后其实看起来就很自然，也没必要死记硬背，当然不了解理论知识这些原则也是很符合常识的。

1 哪些情况适合创建索引

创建索引的总体原则就是尽最大可能缩小数据量，如非要列出一些条条框框的情况，那如下就列了一些：

• 字段的数值有唯一性的限制

  1、索引是排序的，如果是唯一的那找到第一条之后就不用继续找了

• 频繁作为 WHERE 查询条件的字段

  1、索引相对数据数据量小，频繁where意味着扫描的数据块就小

• 经常 GROUP BY 和 ORDER BY 的列

  1、索引是排序的，那你说相同数据挨着一起方不方便分组和排序啊

• UPDATE、DELETE 的 WHERE 条件列

  1、索引相对数据数据量小，频繁where意味着扫描的数据块就小

• DISTINCT 字段需要创建索引

  1、索引是排序的，那你说挨着一起方不方便去重啊

• 多表 JOIN 连接操作时，创建索引注意事项

  • 连接表的数量尽量不要超过 3 张
  • 对 WHERE 条件创建索引
  • 对用于连接的字段创建索引

  以上3点总的来说就是尽最大可能缩小数据量，因为多表JOIN时数据量增长很快，必须把数据量限制在一定的大小

• 使用列的类型小的创建索引

  1、列类型小占用的索引空间就小，扫描时候扫描的块就少

• 使用字符串前缀创建索引

  1、因为有的字符串很长，但是大多数情况下只需要字符串前缀的一部分就可以进行区分，哪怕不能进行区分因为索引是排序的也关系不大

  2、缩小了索引占用的空间

• 区分度高(散列性高)的列适合作为索引

  1、区分度不高我要你干嘛，我直接全表扫描不好吗

• 使用最频繁的列放到联合索引的左侧

  1、索引是排序的

  2、联合索引，先根据第一个字段排序，第一个字段相同排序第二个字段

• 在多个字段都要创建索引的情况下，联合索引优于单值索引

  1、联合索引，先根据第一个字段排序，第一个字段相同排序第二个字段

2 哪些情况不适合创建索引

• 在where中使用不到的字段，不要设置索引

  1、达不到过滤数据，减少数据量的作用

• 数据量小的表最好不要使用索引

  1、数据量小不如全表扫描，建了索引反而要 回表

• 有大量重复数据的列上不要建立索引

  1、失去了索引的意义

• 避免对经常更新的表创建过多的索引

  1、索引也是需要维护的，经常更新意味着索引维护成本过高

• 不建议用无序的值作为索引

  建立索引的目的就是要对无序的值进行排序，还不对无序字段建立索引，胡扯！

• 删除不再使用或者很少使用的索引

  不使用还占用空间，建议删除

• 不要定义冗余或重复的索引

  1、重复几不会加速查询，还是增加了空间成本和维护成本

2 参考资料

InnoDB 行记录格式：参考我的文章：《15.10 InnoDB 行记录格式（理论，重要）.md》、《15.10 InnoDB 行记录格式（实验，重要）.md》

InnoDB 数据页格式：参考我的文章：《15.6.1 InnoDB 数据页格式（数据页理论，重要）.md》、《15.6.1 InnoDB 数据页格式（数据页实验，重要）.md》

InnoDB 索引页格式：参考我的文章：《15.6.2 InnoDB 索引页格式（索引页理论，重要）.md》、《15.6.2 InnoDB 索引页格式（索引页实验，重要）.md》

书籍：《InnoDB 存储引擎》，该书电子版书籍作者无套路免费下载

---

传送门： 保姆式Spring5源码解析

欢迎与作者一起交流技术和工作生活

联系作者