情况一：全列匹配。
　　当按照索引中所有列进行精确匹配(这里精确匹配指“=”或“IN”匹配)时，索引可以被用到。这里有一点需要注意，理论上索引对顺序是敏感的，但 是由于MySQL的查询优化器会自动调整where子句的条件顺序以使用适合的索引
　　情况二：左前缀匹配。
　　当查询条件精确匹配索引的左边连续一个或几个列时，如或，所以可以被用到，但是只能用到一部分，即条件所组成的左前缀。上面的查询从分析结果看用到了PRIMARY索引，但是 key_len为4，说明只用到了索引的第一列前缀。
　　情况三：查询条件用到了索引中列的精确匹配，但是中间某个条件未提供。
　　此时索引使用情况和情况二相同，因为title未提供，所以查询只用到了索引的第一列。如果想让 from_date也使用索引而不是where过滤，可以增加一个辅助索引，此时上面的查询会使用这个索引。除此之外，还可以使用一种称之为“隔离列”的优化方法，将emp_no与from_date 之间的“坑”填上。
　　情况四：查询条件没有指定索引第一列。
　　由于不是左前缀，索引这样的查询显然用不到索引。
　　情况五：匹配某列的前缀字符串。
　　此时可以用到索引，但是如果通配符不是只出现在末尾，则无法使用索引。
　　情况六：范围查询。
　　范围列可以用到索引(必须是左前缀)，但是范围列后面的列无法用到索引。同时，索引多用于一个范围列，因此如果查询条件中有两个范围列则无法全用到索引。
　　情况七：查询条件中含有函数或表达式。
　　很不幸，如果查询条件中含有函数或表达式，则MySQL不会为这列使用索引。显然这个查询等价于查询emp_no为10001的函数，但是由于查询条件是一个表达式，MySQL无法为其使用索引。看来MySQL还没有智能到自动优化常量表达式的程度，因此在写查询语句时尽量避免表达式出现在查询中，而是先手工私下代数运算，转换为无表达式的查询语句。
　　索引建立条件与前缀索引
　　既然索引可以加快查询速度，那么是不是只要是查询语句需要，建上索引?答案是否定的。因为索引虽然加快了查询速度，但索引也是有代价的：索引文件本身要消耗存储空间，同时索引会加重插入、删除和修改记录时的负担，另外，MySQL在运行时也要消耗资源维护索引，因此索引并不是越多越好。一般两种情况下不建议建索引。
　　第一种情况是表记录比较少，例如一两千条甚至只有几百条记录的表，没必要建索引，让查询做全表扫描好了。至于多少条记录才算多，这个个人有个人的看法，我个人的经验是以2000作为分界线，记录数不超过 2000可以考虑不建索引，超过2000条可以酌情考虑索引。
　　另一种不建议建索引的情况是索引的选择性较低。所谓索引的选择性(Selectivity)，是指不重复的索引值(也叫基数，Cardinality)与表记录数(#T)的比值：
　　Index Selectivity = Cardinality / #T
　　显然选择性的取值范围为(0， 1]，选择性越高的索引价值越大，这是由B+Tree的性质决定的。
　　有一种与索引选择性有关的索引优化策略叫做前缀索引，是用列的前缀代替整个列作为索引key，当前缀长度合适时，可以做到既使得前缀索引的选择性 接近全列索引，同时因为索引key变短而减少了索引文件的大小和维护开销。前缀索引兼顾索引大小和查询速度，但是其缺点是不能用于ORDER BY和GROUP BY操作，也不能用于Covering index(即当索引本身包含查询所需全部数据时，不再访问数据文件本身)。
　　InnoDB的主键选择与插入优化
　　在使用InnoDB存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键。
　　经常看到有帖子或博客讨论主键选择问题，有人建议使用业务无关的自增主键，有人觉得没有必要，完全可以使用如学号或身份证号这种字段作为主键。不论支持哪种论点，大多数论据都是业务层面的。如果从数据库索引优化角度看，使用InnoDB引擎而不使用自增主键是一个糟糕的主意。