MySQL为什么在使用索引的情况下能够提高查询效率，不使用索引又会是什么情形

先来个生活学习中直观的体验……查字典

字典都有拼音、偏旁部首或者笔画数三个供检索的部分。

它们能以不同的方式快速定位到某个字词在哪一页。

而且存放这些索引部分的地方很好找，不是字典后面，就是字典前面。

但显然这些索引部分需要额外的纸张来记录。时间成本和材料成本总得有平衡不是？

假如，你的字典没有这些索引部分，你遇到一个很生僻的字，你会怎么查？效率如何？

假如你是杠精，说:没问题啊，我记得所有字存储在字典的哪个地方，那你很6，我无语。

MySQL的索引对象和字典的索引部分就有些像，对不同字段建立索引，就好比字典增加了快速查字词的方式，比如五笔，或者其它。

拼音的索引和MySQL的最像，因为拼音的分段查找更简易通用。

MySQL的查询走索引，好比你查字词通过索引部分，能快速定位目标在字典哪一页。

MySQL的查询不走索引，就好比你查字词不使用字典的索引部分，查不查得到就看运气了，但计算机可能存在很大问题。

我想MySQL的索引设计灵感正是来源于字典的设计。

这样的话，下面的不看应该都能大概理解了

不使用索引会怎样呢？使用了索引又会如何？
假如不使用索引，那么当查找一行记录时，会怎样操作呢？我想到三种方法。
第一种方式:把所有页都加载至内存中，再进行精确的定位和查找。这种方式存在很大的问题，因为我们要查找的行显然只在某一页上，而把所有页都加载进内存，如果数据量很大，内存很可能都装不下这么多页的数据，就算内存能够存储，也只是加载很多没有必要加载的页。
第二种方式:先加载一页的数据，在内存中对这一页进行查找如果找不到想要查找的行，再加载第二页，第三页，……运气差一点，直到加载最后一页才能够确定想要查找的记录是否存在。这种方式页也存在很大的问题，就是频繁的进行磁盘IO操作，造成IO冗余。
第三种方式:一次加载几页数据，在内存中进行精确查找，如果找不到想要查找的行，再加载下一组，……，如此反复执行。这种方式每次加载的数据量比第一种少，但仍然会加载冗余的页，还有可能进行多次磁盘IO操作。显然也不合适。
而如果使用了索引，那么当查找某一行记录时，便可经过很少次数的io就定位到所要查找的行所在的页，并且只需要加载这一页的记录至内存中，在内存中再进行精确的后续操作。这种方式避免了冗余地加载页，同时也避免了大量的、不必要的io操作，从而提高查询效率。
那我们要做的就是建立合适的索引，并使查询语句能够使用索引的方式进行。