索引优化策略
1:索引类型
1.1B-tree索引
关注的是：Btree索引的左前缀匹配规则，索引在排序和分组上发挥的作用。
注:名叫btree索引,大的方面看都用的二叉树、平衡树。但具体的实现上,各引擎稍有不同。比如,严格的说,NDB引擎,使用的是T-tree。Myisam,innodb中,默认用B-tree索引。
凡是tree系列的，可理解为”排好序的、快速查找、的结构”。是排好序的，所以查询某个范围就很快。
btree索引的常见误区：在where条件常用的列上都加上索引，
例: where cat_id=3 and price>100 ; //查询第3个栏目,100元以上的商品
误: cat_id上,和, price上都加上索引.
错:只能用上cat_id或Price索引,因为是独立的索引,同时只能用上1个，因为每个索引都是针对整个表建的，而where and查询是在排好序的大范围内再查找小的。（mysql5.6以后做了稍微改进，把多列索引进行merge但是效果不好），因此要使用多列索引。
在多列上建立索引后,查询哪个列,索引都将发挥作用：
误: 多列索引上,索引发挥作用,需要满足左前缀要求(btree索引的左前缀规则)
B-tree多列索引：
a,b列各加上索引：index(a)和index(b)
Where a=3 and b=5 ，首先根据a查找到a=3的一小段，然后在从这小段中查找b=5的，此时b的索引已经发挥不了作用了。因为b的索引就不是在a的那一小段里面建的。b是针对整个表建的索引。
以 index(a,b,c) ，Where a=3 and b=5 and c=4 为例，联合索引是先根据a划分大类（a是有序的），再根据b在a里面划分小的（a里面的b是有序的），在根据c在b里面划分更小的（c在b里面是有序的）。就是这样查找的（这是tree系列的索引和查找方式）。
Where b=5 and c=4，索引就用不到了，因为首先是根据a分的大类。现在找b=5的，每一个a的区间都可能有b=5的所以首先排好序的a就进不去。
Where a=4 and c=4，a索引用到，c用不到。每段b里面都可能有c=4的。
多列索引：左前缀规则，中间断线就不行了。否则只能使用到部分。
index(a,b,c)：
语句 索引是否发挥作用
Where a=3 是,只使用了a列
Where a=3 and b=5 是,使用了a,b列
Where a=3 and b=5 and c=4 是,使用了abc
Where b=3 or where c=4 否
Where a=3 and c=4 a列能发挥索引,c索引也就不能使用了
Where a=3 and b>10 and c=7 A能利用,b能利用, b是一个范围，在这个范围里面的b[10,20]b[20,30]里面都有可能c=7,所以C不能利用
同上,where a=3 and b like ‘xxxx%’ and c=7 A能用,B能用,C不能用
多列索引经典题目:
http://www.zixue.it/thread-9218-1-4.html
假设某个表有一个联合索引（c1,c2,c3,c4）一下——只能使用该联合索引的c1,c2,c3部分，tree系列里面：c1是有序的,c2在c1里面是有序的,c3在c2里面是有序的,c4在c3里面是有序的。
A where c1=x and c2=x and c4>x and c3=x
B where c1=x and c2=x and c4=x order by c3
C where c1=x and c4= x group by c3,c2
D where c1=x and c5=x order by c2,c3
E where c1=x and c2=x and c5=? order by c2,c3
create table t4 (
c1 tinyint(1) not null default 0,
c2 tinyint(1) not null default 0,
c3 tinyint(1) not null default 0,
c4 tinyint(1) not null default 0,
c5 tinyint(1) not null default 0,
index c1234(c1,c2,c3,c4)
);
insert into t4 values (1,3,5,6,7),(2,3,9,8,3),(4,3,2,7,5);
对于A:where c1=x and c2=x and c4>x and c3=x，
等价c1=x and c2=x and c3=x and c4>x
因此 c1,c2,c3,c4都能用上. 如下:
mysql> explain select * from t4 where c1=1 and c2=2 and c4>3 and c3=3 \G
id: 1
select_type: SIMPLE
table: t4
type: range //使用索引的方式，使用的是范围索引(c4)
possible_keys: c1234
key: c1234
key_len: 4 //4列#可以看出c1,c2,c3,c4索引都用上
ref: NULL
rows: 1
Extra: Using where
对于B: select * from t4 where c1=1 and c2=2 and c4=3 order by c3
c1 ,c2索引用上了，在c2用到索引的基础上，c3是排好序的，因此不用额外排序，c3,c4没发挥作用.
mysql> explain select * from t4 where c1=1 and c2=2 and c4=3 order by c3 \G
id: 1
select_type: SIMPLE
table: t4
type: ref
possible_keys: c1234
key: c1234 //使用了多列索引，但是不一定所有的列都用到了，
key_len: 2 //2列发挥了作用c1c2，
ref: const,const
rows: 1
Extra: Using where
1 row in set (0.00 sec)
mysql> explain select * from t4 where c1=1 and c2=2 and c4=3 order by c5 \G
id: 1
select_type: SIMPLE
table: t4
type: ref
possible_keys: c1234
key: c1234 //多列索引使用到了
key_len: 2 //只是使用到了多列索引中的2列c1c2
ref: const,const
rows: 1
Extra: Using where; Using filesort //Usingfilesort是二次排序，在磁盘或者内存里面，c5是没有顺序的所以取出来之后要排序。
D语句:where c1=x and c5=x order by c2,c3，C1确定的基础上,c2是有序的,C2之下C3是有序的,因此c2,c3发挥的排序的作用.
因此,没用到filesort。只能使用一个索引，c2,c3的索引能够用来排序。
mysql> explain select * from t4 where c1=1 and c5=2 order by c2,c3 \G
id: 1
select_type: SIMPLE
table: t4
type: ref
possible_keys: c1234 //多列索引使用到了
key: c1234
key_len: 1 //只是使用到了多列索引中的1列c1,
ref: const
rows: 1
Extra: Using where //没有Using filesort的文件排序，因为c2c3是排好序的
mysql> explain select * from t4 where c1=1 and c5=2 order by c3 \G
id: 1
select_type: SIMPLE
table: t4
partitions: NULL
type: ref
possible_keys: c1234
key: c1234
key_len: 1
ref: const
rows: 1
filtered: 20.00
Extra: Using index condition; Using where; Using filesort //要排序，因为c3跳过了c2,所以要文件排序（比如国家下面的省，先要国家排序后在省排序。现在跳过国家去排省就要重新排序了），没法利用索引了。
E: where c1=x and c2=x and c5=? order by c2,c3
这一句等价与 elect * from t4 where c1=1 and c2=3 and c5=2 order by c3;
因为c2的值既是固定的,参与排序时并不考虑
mysql> explain select * from t4 where c1=1 and c2=3 and c5=2 order by c2,c3 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t4
type: ref
possible_keys: c1234
key: c1234
key_len: 2 //用到了2列索引，
ref: const,const
rows: 1
Extra: Using where //没有用到文件排序，说明c2c3索引都用到了，
mysql> explain select * from t4 where c1=1 and c5=2 order by c2,c3 \G
id: 1
select_type: SIMPLE
table: t4
partitions: NULL
type: ref
possible_keys: c1234
key: c1234
key_len: 1 //用到了1列索引，
ref: const
rows: 1
filtered: 20.00
Extra: Using index condition; Using where //不用排序，因为先根据cw2排序然后根据c3排序，而c2c3是已经排好序的
mysql> explain select * from t4 where c1=1 and c5=2 order by c3,c2 \G
id: 1
select_type: SIMPLE
table: t4
partitions: NULL
type: ref
possible_keys: c1234
key: c1234
key_len: 1 //用到了1列索引，
ref: const
rows: 1
filtered: 20.00
Extra: Using index condition; Using where; Using filesort //要排序，因为先根据c3排序再根据c2排序，（比如国家下面的省，先要国家排序后在省排序。现在跳过国家去排省就要重新排序了）
mysql> explain select * from t4 where c1=1 and c2=3 and c5=2 order by c3,c2 \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t4
partitions: NULL
type: ref
possible_keys: c1234
key: c1234
key_len: 2
ref: const,const
rows: 1
filtered: 20.00
Extra: Using index condition; Using where //没有排序，虽然c3在c2的前面，但是c2是定值。
mysql> select cat_id,avg(shop_price) from goods group by cat_id;
+--------+-----------------+
| cat_id | avg(shop_price) |
+--------+-----------------+
| 2 | 823.330000 |
| 3 | 1746.066667 |
| 4 | 2297.000000 |
| 5 | 3700.000000 |
| 8 | 75.333333 |
| 11 | 31.000000 |
| 13 | 33.500000 |
| 14 | 54.000000 |
| 15 | 70.000000 |
+--------+-----------------+
mysql> explain select cat_id,avg(shop_price) from goods group by cat_id \G;
id: 1
select_type: SIMPLE
table: goods
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 31
filtered: 100.00
Extra: Using temporary; Using filesort //分组操作的时候要先排序，这里Using temporary根据cat_id进行排序，使用的是临时表排序，如果将cat_id加上索引，那么cat_id已经排好序了，就不需要使用临时表来排序。（有可能加了索引还是使用了临时表，那是因为mysql做了自动优化.）
mysql> alter table goods add index catid_index(cat_id);
对于C where c1=x and c4= x group by c3,c2
只用到c1索引,因为group by c3,c2的顺序无法利用c2,c3索引
mysql> explain select * from t4 where c1=1 and c4=2 group by c3,c2 \G
id: 1
select_type: SIMPLE
table: t4
type: ref
possible_keys: c1234
key: c1234
key_len: 1 #只用到c1,因为先用c3后用c2分组,导致c2,c3索引没发挥作用
ref: const
rows: 1
Extra: Using where; Using temporary; Using filesort//并且还要排序
mysql> explain select * from t4 where c1=1 and c4=2 group by c2,c3 \G
id: 1
select_type: SIMPLE
table: t4
type: ref
possible_keys: c1234
key: c1234
key_len: 1
ref: const
rows: 1
Extra: Using where
1 row in set (0.00 sec)
1.2 hash索引(数据散的放的)
在memory表里,默认是hash索引,hash的理论查询时间复杂度为O(1)，O(1)是说任意给一行，理论上一次就能够找到。
疑问: 既然hash的查找如此高效,为什么不都用hash索引?
答:1:hash函数计算后的结果是随机的,如果是在磁盘上放置数据,随机查询是非常慢的。虽然算这行数据在哪里算的很快，但是去取这行数据的时候就很慢。
比如主键为id为例, 那么随着id的增长, id对应的行,在磁盘上随机放置.
2: 不法对范围查询进行优化，随机的范围查找慢。
3: 无法利用前缀索引. 比如在btree中,field列的值"hellopworld并加索引查询xx=helloword,自然可以利用索引, xx=hello,也可以利用索引(左前缀索引)，而利用hash索引，因为hash('helloword')和hash('hello')就是截然不同的结果，所以没法利用前缀优化。
4: 排序也无法利用hash索引来优化.
5: 必须回行.就是说 通过索引拿到数据位置,必须回到表中取数据
