对于小表，全表扫描更有效，中型和大型的表索引更有效，对于特大型的表，使用索引将会增加成本，这时可以使用分区技术。 另外索引越多，则insert update delete速度越慢。
索引有很多种类型，在Mysql中，索引是在存储引擎层而不是服务器层实现的，所以无统一标准，不同存储引擎的索引工作方式是不一样的，即使多个存储引擎支持同一一种类型的索引，其底层实现也可能不一样。myisam以前缀压缩技术使得索引变的更小，Innodb按照原数据格式进行存储。
B-Tree类型索引
大家谈论的索引，如果没指明类型，那一般就是指B-Tree类型索引，B-Tree索引采用B+树索引来存储数据，这种结构适合顺序存储 B-Tree通常意味着所有的值都是按照按照顺序存储的，所以B-Tree索引是很适合查找范围数据的 如查找I到K之间的字母。
可以使用B-Tree索引的查询类型：
以一下建表语句为例，
索引存储数据如下：
B-Tree 索引适用情况
全值匹配：和索引中的所有列进行匹配。如查找 姓名 为 Cuba Allen 出生在1960-01-01的人
匹配最左前缀：只匹配索引的第一列(联合索引的第一列)，即查找姓为 Allen的人
匹配列前缀：也可以匹配某列值得开头的部分 如查找所有姓以J开头的的人 like ‘1234%’。
匹配范围值：前面说过B树索引适合范围查找，那么 查找姓在Allen和Barry之间的人 或者age>20 and age <50 会使用B树索引。
精确某一列并范围匹配另一列：查找姓为Allen 名是以K开头的人，第一列精确查找，第二轮范围匹配(假设联合索引有四列，是否也适用于 精确查找第一列，第二列，范围查找第三列？答案：是)
因为索引树节点是有序的，除了按值查找之外还可以用于ORDER BY 操作，一般来说B-Tree 可以按照某种方式查找到值，那么也可以按照这种方式排序，所以上面的那些情况也可以用于ORDER BY，GROUP BY ,DISTINCT 。
B-Tree的限制
1:如果不是按照索引的最左列查找,则无法使用索引，上面的查询中 无法名字为Bill或者生日为xxxx-xx-xx的人，因为不是最左列。
2: 不能跳过索引列的顺序，即不能查找姓为xx且生日在xxxx-xx-xx的人，要按照索引列的顺序来。
3: 如果使用索引某个列的范围查询，则其右边的列都无法使用索引，如 where last_name = ‘Smith’ and first_name like ‘J%’ and dob = ‘2000-04-04’ 这里查询只会使用索引的前两列，因为like是范围查询。
4: Not IN 和<> 操作无法使用索引
从上面的描述可以看出，索引列的顺序非常重要.
哈希索引
哈希索引是基于哈希函数的实现，只有精确所有列的查询才有效，哈希索引存的数据结构只有两列（哈希码，对应数据行的指针）
哈希索引由于使用哈希表实现的 所以只支持全列精确查找（= ,IN(),<>,<=>这些），像范围查询 排序查询 都不能使用。
全文索引
使用索引的技巧
1 :where条件中不要对索引进行计算(包括几何计算，函数计算等等) ,如 select name from user where user_id+1=5;
可以修改为where user_id = 5-1
2:多列索引？（多个列建立索引还是一个索引包含多列？ 为什么要这样做？）
3选择合适的索引顺序：将选择性（唯一值的个数与总行数的比值，比值越高说明选择性越高）最高的列放在索引的最前列（为什么是选择性而不是最常用？）当无ORDER BY GROUP BY 的时候，这样做是一个不错的选择，这时索引的作用只是优化查询的效率，选择性最高的列放最前可以快速过滤结果行。select count(distinct colum1)/count(1) as selectivity1, count(distinct colum2)/count(1) as selectivity2 from table ，查询各列的选择性
4聚蔟索引
5冗余索引和重复索引：重复索引是指相同列上的按照相同顺序创建的相同类型的索引
一下就属于重复索引 key(a.b),key(a), 因为a是第一个索引的前缀索引 因此再创建a就是冗余索引，但是key(b) 不是冗余索引 因为b不是前缀索引，