原因很简单，索引B 树中行数据按照索引值排序，只能根据前缀进行比较。如果要按照后缀搜索也希望走索引的话，并且永远只是按照后缀搜索的话，可以把数据反过来存，用的时候再倒过来。
第二，条件涉及函数操作无法走索引。比如搜索条件用到了LENGTH函数，肯定无法走索引：
EXPLAIN SELECT * FROM person WHERE LENGTH(NAME)=7
同样的原因，索引保存的是索引列的原始值，而不是经过函数计算后的值。如果需要针对函数调用走数据库索引的话，只能保存一份函数变换后的值，然后重新针对这个计算列做索引。
第三，联合索引只能匹配左边的列。也就是说，虽然对name和score建了联合索引，但是仅按照score列搜索无法走索引：
EXPLAIN SELECT * FROM person WHERE SCORE>45678
原因也很简单，在联合索引的情况下，数据是按照索引第一列排序，第一列数据相同时才会按照第二列排序。也就是说，如果我们想使用联合索引中尽可能多的列，查询条件中的各个列必须是联合索引中从最左边开始连续的列。如果我们仅仅按照第二列搜索，肯定无法走索引。尝试把搜索条件加入name列，可以看到走了name_score索引：
EXPLAIN SELECT * FROM person WHERE SCORE>45678 AND NAME LIKE 'NAME45%'
需要注意的是，因为有查询优化器，所以name作为WHERE子句的第几个条件并不是很重要。
现在回到最开始的两个问题。
- 是不是建了索引一定可以用上？并不是，只有当查询能符合索引存储的实际结构时，才能用上。这里，我只给出了三个肯定用不上索引的反例。其实，有的时候即使可以走索引，MySQL也不一定会选择使用索引。我会在下一小节展开这一点。
- 怎么选择建联合索引还是多个独立索引？如果你的搜索条件经常会使用多个字段进行搜索，那么可以考虑针对这几个字段建联合索引；同时，针对多字段建立联合索引，使用索引覆盖的可能更大。如果只会查询单个字段，可以考虑建单独的索引，毕竟联合索引保存了不必要字段也有成本。
通过前面的案例，我们可以看到，查询数据可以直接在聚簇索引上进行全表扫描，也可以走二级索引扫描后到聚簇索引回表。看到这里，你不禁要问了，MySQL到底是怎么确定走哪种方案的呢。
其实，MySQL在查询数据之前，会先对可能的方案做执行计划，然后依据成本决定走哪个执行计划。
这里的成本，包括IO成本和CPU成本：
- IO成本，是从磁盘把数据加载到内存的成本。默认情况下，读取数据页的IO成本常数是1（也就是读取1个页成本是1）。
- CPU成本，是检测数据是否满足条件和排序等CPU操作的成本。默认情况下，检测记录的成本是0.2。
基于此，我们分析下全表扫描的成本。
全表扫描，就是把聚簇索引中的记录依次和给定的搜索条件做比较，把符合搜索条件的记录加入结果集的过程。那么，要计算全表扫描的代价需要两个信息：
- 聚簇索引占用的页面数，用来计算读取数据的IO成本；
- 表中的记录数，用来计算搜索的CPU成本。
那么，MySQL是实时统计这些信息的吗？其实并不是，MySQL维护了表的统计信息，可以使用下面的命令查看：
SHOW TABLE STATUS LIKE 'person'
输出如下：
