©2020-2024 ioDraw All rights reserved,
Privacy Policy
前面其实写了好几篇关于 mysql 索引的文章了，文章中有具体的实例和 sql 语句，这篇文章我想再用纯大白话讲讲 mysql 索引，文中不涉及具体 sql
。
我之前甚至想过为啥要用数据库来保存数据，用普通的 txt 或者 word
这类文件不行么，这个问题其实可以从几个方面来看，一个是并发访问数据加锁，另一个是数据安全性，再一个是数据的查询性能问题。这三个方面在 mysql
中都有对应的解决方案，比如事务、锁、日志系统(binlog、redolog 等)、索引。
为了实现高效查询，就得找到一种合适的数据结构来保存数据。首先我们可以想到使用哈希表，哈希表能通过键值快速找到对应的值，但是因为哈希是无序的，一般更适用于等值查询，但实际业务中通过会有大量的区间查询，比如查询
id 在 1-100 间的值，使用哈希的话效率就会大打折扣了。
那么就要找到一种既能满足等值查询，又能满足区间查询的数据结构了，又会很容易想到数组。数组可以通过下标快速找到对应的值，因为数组下标是有序的，所以通过遍历下标就能很高效的完成区间查询。
但是数组也有一个严重的问题，就是在删除或者插入数据的时候可能会移动大量其他数据，这是一个很大的性能消耗，所以数组一般更适合保存静态数据，比如一些历史数据，确定不会再更新的数据。
再一个就是二叉搜索树了，二叉搜索树的查找效率比较高，而且二叉搜索树的中序遍历就是一个有序数组，但依然不能很好的支持区间查询。
所以可以对二叉搜索树进行改造，树的节点不再保存具体数据，而是保存索引值，数据保存在最底层的叶子节点上，同时叶子节点间使用双链表连接起来，这样只需要先找到区间起始值的位置，然后往后遍历到终止值，即可完成区间查询。
事实上 mysql 底层采用的 B+ 树也就是这么一步步演变过来的，关于 B+ 树的详细介绍可以参考我前面的文章。
另外说一点，mysql
中有一个非常重要的模块，就是优化器，优化器的主要任务就是寻找一种更低代价方式去执行方式，通常会以扫描行数、是否需要排序、是否需要回表、是否需要临时表等来作为代价依据。
所以通常同一条 sql 在不同数据量的情况下执行情况可能会不一样，或者明明为某些 where
字段建立了索引，查询的时候偏偏又不走索引，这些情况其实都是经过优化器分析后作出的选择。因此你要知道，一条 sql 最终该怎么执行，还得看是在什么样的场景。