侧边栏壁纸
博主头像
落叶人生博主等级

走进秋风,寻找秋天的落叶

  • 累计撰写 143952 篇文章
  • 累计创建 28 个标签
  • 累计收到 9 条评论
标签搜索

目 录CONTENT

文章目录

mysql数据库索引为什么失效--你查的太多了

2024-02-21 星期三 / 0 评论 / 0 点赞 / 6 阅读 / 2697 字

我们知道,在进行数据库的查询时候,如果加入了索引,将会大大提升查询的效率,但是,在很多的时候,即使加上了索引也会有索引失效的时候。今天,我们主要来看这样一种情况: 查询的数据库条数过多的时候首先,我

我们知道,在进行数据库的查询时候,如果加入了索引,将会大大提升查询的效率,但是,在很多的时候,即使加上了索引也会有索引失效的时候。

今天,我们主要来看这样一种情况: 查询的数据库条数过多的时候

首先,我们先在数据库里创建一张表:

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的记录,看插入多少数据的时候会再次走索引,也就知道了自己安装的数据库不走索引的临界值是多少了。

广告 广告

评论区