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

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

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

来源:链接

您必须知道的第一件事是，索引是一种避免扫描整个表以获得您正在寻找的结果的方法。

有不同种类的索引，它们是在存储层实现的，所以它们之间没有标准，它们也取决于你使用的存储引擎。

InnoDB和B+树索引

对于InnoDB，最常见的索引类型是基于B+树的索引，它以排序的顺序存储元素。此外，您不必访问实际表来获取索引值，这使得您的查询返回速度更快。

关于这种索引类型的“问题”是，您必须查询最左边的值才能使用索引。因此，如果您的索引有两个列，例如last_name和first_name，那么查询这些字段的顺序非常重要。

给定下面的表格:

CREATE TABLE person (
    last_name VARCHAR(50) NOT NULL,
    first_name VARCHAR(50) NOT NULL,
    INDEX (last_name, first_name)
);

这个查询将利用索引:

SELECT last_name, first_name FROM person
WHERE last_name = "John" AND first_name LIKE "J%"

但接下来的一个则不然

SELECT last_name, first_name FROM person WHERE first_name = "Constantine"

因为首先查询的是first_name列而不是索引中最左边的列。

最后一个例子更糟糕:

SELECT last_name, first_name FROM person WHERE first_name LIKE "%Constantine"

因为现在，你比较的是索引中最右边字段的最右边部分。

哈希索引

这是一种不同的索引类型，不幸的是，只有内存后端支持。它速度极快，但仅对完全查找有用，这意味着您不能将其用于>、<或like等操作。

因为它只适用于内存后端，所以您可能不会经常使用它。我现在能想到的主要情况是，您在内存中创建一个临时表，其中包含来自另一个选择的一组结果，并使用散列索引在这个临时表中执行许多其他选择。

如果您有一个大的VARCHAR字段，您可以在使用B-Tree时“模拟”使用哈希索引，方法是创建另一列并在其中保存大值的哈希。假设您要在字段中存储一个url，值相当大。您还可以创建一个名为url_hash的整数字段，并在插入url时使用像CRC32这样的哈希函数或任何其他哈希函数来哈希。然后，当你需要查询这个值时，你可以这样做:

SELECT url FROM url_table WHERE url_hash=CRC32("http://gnu.org");

上述示例的问题在于，由于CRC32函数生成了一个非常小的散列，因此最终会在散列值中产生大量冲突。如果你需要精确的值，你可以通过以下方法修复这个问题:

SELECT url FROM url_table 
WHERE url_hash=CRC32("http://gnu.org") AND url="http://gnu.org";

即使碰撞数很高，哈希仍然是值得的，因为你只会对重复的哈希执行第二次比较(字符串一)。

不幸的是，使用这种技术，您仍然需要点击表来比较url字段。

总结

每当你想谈论优化时，你可能会考虑一些事实:

整数比较比字符串比较快得多。以InnoDB中哈希索引仿真为例进行了说明。 也许，在流程中添加额外的步骤会使其更快，而不是更慢。可以通过以下事实来说明这一点:优化SELECT可以分为两个步骤，第一个步骤将值存储在新创建的内存表中，然后在第二个表上执行较重的查询。

MySQL也有其他索引，但我认为B+树索引是最常用的，哈希索引是一个很好的东西，但你可以在MySQL文档中找到其他索引。

我强烈推荐你去读“高性能MySQL”这本书，上面的答案肯定是基于它关于索引的章节。

基本上表上的索引就像书中的索引一样(这就是这个名字的由来):

Let's say you have a book about databases and you want to find some information about, say, storage. Without an index (assuming no other aid, such as a table of contents) you'd have to go through the pages one by one, until you found the topic (that's a full table scan). On the other hand, an index has a list of keywords, so you'd consult the index and see that storage is mentioned on pages 113-120,231 and 354. Then you could flip to those pages directly, without searching (that's a search with an index, somewhat faster).

当然，索引的有用程度取决于许多事情——举几个例子，使用上面的明喻:

if you had a book on databases and indexed the word "database", you'd see that it's mentioned on pages 1-59,61-290, and 292 to 400. In such case, the index is not much help and it might be faster to go through the pages one by one (in a database, this is "poor selectivity"). For a 10-page book, it makes no sense to make an index, as you may end up with a 10-page book prefixed by a 5-page index, which is just silly - just scan the 10 pages and be done with it. The index also needs to be useful - there's generally no point to index e.g. the frequency of the letter "L" per page.

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

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

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

来源:链接

看这个视频了解更多关于索引的细节

简单的索引 您可以在表上创建唯一的索引。唯一索引意味着两行不能有相同的索引值。下面是在表上创建Index的语法

CREATE UNIQUE INDEX index_name
ON table_name ( column1, column2,...);

您可以使用一个或多个列来创建索引。例如，我们可以使用tutorial_author在tutorials_tbl上创建索引。

CREATE UNIQUE INDEX AUTHOR_INDEX
ON tutorials_tbl (tutorial_author)

您可以在表上创建一个简单的索引。只需从查询中省略UNIQUE关键字以创建简单的索引。简单索引允许表中有重复的值。

如果要按降序索引列中的值，可以在列名后添加保留字DESC。

mysql> CREATE UNIQUE INDEX AUTHOR_INDEX
ON tutorials_tbl (tutorial_author DESC)

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

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

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

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

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

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