mysql优化（二）索引

B-tree索引

可以理解为“排序好的快速查找结构”，从大的方面看用的都是平衡树，但具体的实现上各引擎稍微有不同，比如严格地说NDB使用的是T-tree

---

假设一张表内有7个用户，让你取出5号用户，你只能从前到后挨个对比，然后在第五次找到；运气好id为1一次就找到，运气差id为7要找7次才能找到，如果有1亿条数据，平均找n/2次也得找5000万次才能找到

---

现在有btree就大不一样了，如图

还是找5号用户，第一次判断5>4,到6的节点，判断6<5，到5的节点，3次就找到了。这里结果可能和上面平均结果差不多，但设想如果是42亿数据（int型的最大值），上图找法平均要找21亿次，而btree树只要找32次就一定能找到。
因为树的第一层，放2的0次方，树的第二层放2的1次方，第三层放2的2次方，以此类推32层的树就完全放完了42亿数据，所以运气再差查询也只要32次
找到5之后，就能获取存储在磁盘上位置行的信息，所以找数据的流程其实是现在索引树上跑，找到索引，然后根据索引信息去取数据，以myisam为例，假设有一张user表，你会发现它其实有3个文件

• user.frm 表的结构说明
• user.myd 数据
• user.myi 树

hash索引

在memory里默认是hash索引，hash的理论查询时间复杂度为O(1),意味着不管有几十亿条数据，理论上只用查询一次就能找到。
那hash是怎么实现的呢，简单地说，哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+tree那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。
但有优点就有缺点，hash也是不是万能的，它依然有一些缺点和限制：

• hash索引仅仅能满足=、in、<=>查询，不能使用范围查询，只能精准查询
• 无法利用前缀索引
• 排序无法优化
• 不能避免表扫描