其实我之前写过几篇关于mysql索引的文章。 文章中有具体的例子和sql语句。 这篇文章我想用纯白话讲讲mysql索引。 文章不涉及具体sql。

我什至思考过为什么我们需要使用数据库来保存数据。 为什么不使用普通的txt或word文件呢？ 这个问题其实可以从几个方面来看。 一是并发访问数据锁定，二是数据安全。 性能，另一个是数据的查询性能。 这三个方面在mysql中都有相应的解决方案，比如事务、锁、日志系统（等等）、索引。

为了实现高效的查询，需要找到合适的数据结构来保存数据。 首先，我们可以想到使用哈希表。 哈希表可以通过键值快速找到对应的值。 不过，由于哈希是无序的，所以一般更适合等价查询。 但在实际业务中，会出现大量的区间查询。 比如查询id在1-100之间的值，如果使用hash的话效率会大大降低。

那么我们需要找到一种既能满足相等查询又能满足区间查询的数据结构，很容易想到数组。 数组可以通过下标快速找到对应的值。 由于数组下标是有序的，通过遍历下标可以高效完成区间查询。

不过数组也有一个严重的问题，就是在删除或者插入数据的时候，可能会移动大量的其他数据，这对性能消耗是很大的，所以数组一般比较适合存储静态数据，比如一些历史数据数据，绝对不会再使用。 更新数据。

另一种是二叉搜索树。 二叉搜索树的搜索效率比较高，而且二叉搜索树的中序遍历是有序数组，但是仍然不能很好的支持区间查询。

因此，二叉搜索树可以进行改造。 树的节点不再存储具体数据，而是存储索引值。 数据存储在最低叶节点上。 同时，叶子节点使用双链表连接。 这样，只需要找到区间起始值的位置，然后遍历回终止值，就可以完成区间查询。

事实上，mysql底层使用的B+树是一步一步演化而来的。 关于B+树的详细介绍可以参考我之前的文章。

另外，mysql中有一个非常重要的模块，就是优化器。 优化器的主要任务是找到一种成本更低的执行方式，通常根据扫描行数、是否需要排序、是否需要回表、是否需要临时表等作为成本依据。

因此，通常同一条SQL在不同数据量下的执行结果可能会不同，或者是明确为某些where字段建立了索引，但查询时却没有使用索引。 这些情况实际上是优化器分析后确定的。 选择。 因此，您需要根据场景来了解一条SQL语句最终是如何执行的。