MyISAM引擎的B+Tree索引结构

我们知道对于MyISAM引擎而言，数据文件和索引文件是分离的。从图中也可以看出，通过索引查找到后，就得到了数据的物理地址，然后根据地址定位数据文件中的记录即可。这种方式也叫"非聚集索引"。

而对于Innodb引擎而言，数据文件本身是索引文件！通俗点说，叶子节点上，MyISAM存储的是记录的物理地址，而Innodb上存储的是数据内容，这种方式即"聚集索引"。

另外一点需要注意的是，对于Innodb而言，主键索引中叶子节点存储的是数据内容，而普通索引的叶子节点中存储的是主键值！也就是说，对于Innodb的普通索引字段查找，先通过普通索引的B+Tree查找到主键后，然后通过主键索引的B+Tree进行查找。从这里你可以看出，对于Innodb而言，主键的建立非常重要！

而对于MyISAM而言，主键索引和普通索引仅仅的区别在于主键只需要查找到一条记录即可停止，而普通索引允许重复，找到一条记录后需要继续查找，在结构上没有区别，如上图所示。

深入B+Tree

提几个问题：

为什么B+Tree把真实的数据放到叶子节点，而不是内层节点？

为什么我们说索引字段要尽可能短，最好是单调递增的？

为什么复合索引存在最左匹配原则？

范围查询(>,

关于B+Tree的一些数学理论，咱们就不玩了，至少一点可以肯定的是：数据表的数据量N=F(树的高度h，每个Block存储的索引的个数m)。在N一定的情况下，索引字段越小，那么m会越大，这意味着h将越小！树越低，当然查找的更快！

如果内层节点存放真实的数据，显然m会变小，树将变高。

在实际应用中，我们应该尽可能采用单调递增的字段作为主键，一方面不会使得索引的数据结构变大，减小了索引占用的空间；另一方面也不会频繁的分裂B+Tree，使得效率下降。

比如复合索引(name,age,sex)，B+Tree会优先比较name来确定下一步的搜索方向。如果突然来了个(age,sex)，根本上就无从下手。这也是符合常理的，对于一本书，我们说“找到第几章第几节的XXX”，从没有听说过“找到第几节的XXX”！这是复合索引的重要特性，即最左匹配特性。

假设存在复合索引(name,age,sex)，我们在进行select的时候，并没有按照这个顺序进行，而是sex = 'man' and name = 'zfz' and age = 27，是否会使用索引呢？数据库是很聪明的，在SQL优化的时候，会自动帮助我们调整！但是如果缺失了复合索引的第一列，数据库也将无能为力呢。

对于最左匹配，MySQL会一直向右匹配直到遇到范围查询就停止匹配。什么意思？比如复合索引(name,age,sex)，对于name = 'zhangfengzhe' and age > 26 and sex = 'man'，实际上只利用到了复合索引的name列。

想利用索引，就得“干净”

什么叫“干净”？就是不要让索引参与计算！比如在索引上应用函数，很可能导致索引失效。为什么呢？

其实不用想，B+Tree上存储的是数据，要比较的话，需要把所有的数据都应用上函数，显然成本太大。

想建立索引，看看区分度

索引虽然物美价廉，但是也别乱来。count(distinct col) / count(*)可以算一下col的区分度，显然对于主键而言，就是1。区分度太低的话，可以考虑下，是否还有必要建立索引呢？

Hash索引

这里并不是要深入分析Hash索引，而是要说明一下Hash的思想真是无处不在！

在MySQL的Memory存储引擎中，存在hash函数，给一个key，通过hash函数进行计算得到地址，所以通常情况下，hash索引查找，会非常快，O(1)的速度。但是也存在hash冲突，和HashMap一样，通过单链表的形式解决。

思考下，hash索引是否支持范围查询呢？

显然是不支持的，它只能给一个KEY去查找。就如同HashMap一样，查找key包含"zhangfengzhe"的，会很快么？

SQL优化神器：explain

SQL优化的场景很多，网上的技巧也很多，完全记不住！

要想彻底解决这个问题，我想只有把索引背后的数据结构和原理做适当的理解，遇到书写SQL或者SQL慢查询的时候，我们有基础去分析，再利用好explain工具去验证，就应该问题不大呢。

explain查询的结果，可以告诉你哪些索引正在被使用，表是如何被扫描的等等。这里我将演示个Demo。

数据表student：