我们知道，在进行数据库的查询时候，如果加入了索引，将会大大提升查询的效率，但是，在很多的时候，即使加上了索引也会有索引失效的时候。今天，我们主要来看这样一种情况： 查询的数据库条数过多的时候首先，我
我们知道，在进行数据库的查询时候，如果加入了索引，将会大大提升查询的效率，但是，在很多的时候，即使加上了索引也会有索引失效的时候。
今天，我们主要来看这样一种情况： 查询的数据库条数过多的时候
首先，我们先在数据库里创建一张表：
create table t ( id int PRIMARY KEY AUTO_INCREMENT, name varchar (20), score int );
<br/>我们再向表里插入一些数据：
insert into t (name, score) VALUES ('Lily', 11),('Mike',88),('Candy',38),('Job', 34),('Bob',56),('David',44);我们再在score字段加上索引：
alter table t add index idx_score (score);我们如果想查出得分在56的人，我们用执行计划执行下：
EXPLAIN select * from t where score = 56;得出结果如下：
很明显，因为我们在score字段加上了索引，所以我们在进行查找的时候，就会使用到相关的索引。
但如果我们想要查找分数在56之下的数据，如果执行下，会有什么样的效果呢？执行如下：
EXPLAIN select * from t where score = 56;执行结果如下：
纳尼，为什么在加上了索引之后，执行的时候却没有走索引呢？是不是数据库傻掉了呢？
放心，数据库并没有傻掉，是因为数据库的大师们在设计数据库的时候，创建了这样一个机制，如果在执行的时候预判查出的数据占整张表数据量达到或大于20%，那么会认为这个时候走全表扫描更快一些，这个时候就不会走索引了。
那么为什么会认为走全表扫描更快一些呢？我们知道，通过创建的索引能够直接查到的并不是数据库的所有记录，而是数据库中的主键，然后通过主键的位置去真正存储数据的地方去查找数据。那如果通过索引找到的数据过多，去数据库真正存储数据的地方查询的次数就越多，那么就要进行频繁的寻址与io操作，那这个时候就不如进行全表扫描来的快。
如果有兴趣，大家可以把原有的表里插入一部分大于56的数据，然后再用查询计划查找小于56的记录，看插入多少数据的时候会再次走索引，也就知道了自己安装的数据库不走索引的临界值是多少了。
