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、<=>查询，不能使用范围查询，只能精准查询
• 没法利用前缀索引
• 排序没法优化
• 不能避免表扫描