1.2 hash索引 在memory表里,默认是hash索引, hash的理论查询时间复杂度为O(1) 疑问: 既然hash的查找如此高效,为什么不都用hash索引? 答:
1:hash函数计算后的结果,是随机的,如果是在磁盘上放置数据,比如主键为id为例,那么随着id的增长, id对应的行,在磁盘上随机放置.
2: 不法对范围查询进行优化.
3: 无法利用前缀索引.比如 在btree中, field列的值“hellopworld”,并加索引，查询 xx=helloword,自然可以利用索引, xx=hello,也可以利用索引. (左前缀索引)。因为hash(‘helloword’),和hash(‘hello’),两者的关系仍为随机，其实就是因为HASH是精准的
4: 排序也无法优化. 5: 必须回行.就是说 通过索引拿到数据位置,必须回到表中取数据
二.btree索引的常见误区 2.1 在where条件常用的列上都加上索引 例: where cat_id=3 and price>100 ; //查询第3个栏目,100元以上的商品 误: cat_id上,和, price上都加上索引. 错: 只能用上cat_id或Price索引,因为是独立的索引结构,同时只能用上1个。详细排列叙述，请见Mysql-索引结构直观图解
2.2 多列索引上,索引发挥作用,需要满足左前缀要求. 误: 在多列上建立索引后,查询哪个列,索引都将发挥作用
以 index(a,b,c) 为例,
三.总结： 1.联合索引的顺序遵循左前缀原理，必须层层连贯，SQL语句中where条件没有前后关系， 如上边4，5查询举例 2.涉及到like < > 等范围查询，此查询后的索引用不上 如7 3.在1层层嵌套的前提下，用到了order排序，order排序不参加where条件,注意[where 字段a order by 字段a] 的问题，其实[order a ]假命题，因为已经 等于a 了还排哪门子序 4.在 select查询中的where,多个条件无顺序，但是索引添加时得注意顺序，同一。 5.group 在分组中的工作原理：先order_by 排序 ，创建临时表，如果建了索引，就能省去创建临时表，所以索引对group有效
更多总结：
Mysql-索引总结 ：
http://blog.csdn.net/ty_hf/article/details/53526405
参考地址：http://blog.csdn.net/gongpulin/article/details/52121718