Let's suppose you have a book, probably a novel, a thick one with lots of things to read, hence lots of words. Now, hypothetically, you brought two dictionaries, consisting of only words that are only used, at least one time in the novel. All words in that two dictionaries are stored in typical alphabetical order. In hypothetical dictionary A, words are printed only once while in hypothetical dictionary B words are printed as many numbers of times it is printed in the novel. Remember, words are sorted alphabetically in both the dictionaries. Now you got stuck at some point while reading a novel and need to find the meaning of that word from anyone of those hypothetical dictionaries. What you will do? Surely you will jump to that word in a few steps to find its meaning, rather look for the meaning of each of the words in the novel, from starting, until you reach that bugging word.

这就是SQL中索引的工作方式。假设字典A是PRIMARY INDEX，字典B是KEY/SECONDARY INDEX，并将获取单词含义的愿望作为QUERY/SELECT语句。 索引将有助于以非常快的速度获取数据。如果没有索引，您将不得不从头开始查找数据，这是一项不必要的耗时且昂贵的任务。

有关索引和类型的更多信息，请看这个。

我想发表我的意见。我还远不是数据库专家，但我最近读了一些关于这个主题的文章;足以让我试着申请ELI5。所以，这是一个外行的解释。

我的理解是，索引就像你的表的迷你镜子，很像一个关联数组。如果你给它一个匹配的键，那么你可以在一个“命令”中跳转到那一行。

但是如果没有索引/数组，查询解释器必须使用for循环遍历所有行并检查是否匹配(全表扫描)。

拥有索引的“缺点”是额外的存储空间(用于迷你镜像)，而“优点”是更快地查找内容。

请注意(依赖于您的db引擎)创建主键、外键或唯一键会自动设置各自的索引。同样的原理基本上就是这些钥匙为什么以及如何工作。

Let's suppose you have a book, probably a novel, a thick one with lots of things to read, hence lots of words. Now, hypothetically, you brought two dictionaries, consisting of only words that are only used, at least one time in the novel. All words in that two dictionaries are stored in typical alphabetical order. In hypothetical dictionary A, words are printed only once while in hypothetical dictionary B words are printed as many numbers of times it is printed in the novel. Remember, words are sorted alphabetically in both the dictionaries. Now you got stuck at some point while reading a novel and need to find the meaning of that word from anyone of those hypothetical dictionaries. What you will do? Surely you will jump to that word in a few steps to find its meaning, rather look for the meaning of each of the words in the novel, from starting, until you reach that bugging word.

这就是SQL中索引的工作方式。假设字典A是PRIMARY INDEX，字典B是KEY/SECONDARY INDEX，并将获取单词含义的愿望作为QUERY/SELECT语句。 索引将有助于以非常快的速度获取数据。如果没有索引，您将不得不从头开始查找数据，这是一项不必要的耗时且昂贵的任务。

有关索引和类型的更多信息，请看这个。

基本上，索引是所有按顺序排序的键的映射。有了一个按顺序排列的列表，它就不需要检查每个键，而是可以这样做:

1:去列表的中间-比我想要的高还是低?

2:如果高，就去中间和底部的中间点，如果低，就去中间和顶部的中间点

3:是高还是低?再次跳转到中间点，等等。

使用该逻辑，您可以在大约7步的时间内在排序列表中找到一个元素，而不是检查每一项。

显然，这里有很多复杂的东西，但这给了你基本的概念。

在答案列表中添加一些可视化表示。

MySQL使用了一个额外的间接层:次要索引记录指向主索引记录，主索引本身保存磁盘上的行位置。如果行偏移量发生变化，则只需要更新主索引。

注意:磁盘数据结构在图中看起来是平面的，但实际上是一个 B +树。

来源:链接

索引用于快速查找具有特定列值的行。如果没有索引，MySQL必须从第一行开始，然后通读整个表以找到相关的行。桌子越大，花费就越多。如果表中存在相关列的索引，MySQL可以快速确定要在数据文件中间查找的位置，而不必查看所有数据。这比按顺序读取每一行快得多。

索引添加一个包含搜索条件列和指针的数据结构 对象所在行的内存磁盘地址 其他信息 对索引数据结构进行排序，优化查询效率 该查询查找索引中的特定行;索引指向将查找剩余信息的指针。 索引将查询必须搜索的行数从17减少到4。