mysql为什么用了索引还是ALL_MySQL热点面试题:为什么我使用了索引,查询还是慢?...

本文探讨了为何在MySQL中使用了索引但查询仍可能变慢的问题。通过案例分析,解释了是否使用索引与慢查询之间的关系并不直接,执行时间是决定因素。全索引扫描可能导致查询变慢,强调了索引过滤性的重要性。此外,文章提到了回表的代价以及如何通过优化如index condition pushdown和虚拟列来减少回表次数,提高查询效率。
摘要由CSDN通过智能技术生成

经常有同学问我,我的一个SQL语句使用了索引,为什么还是会进入到慢查询之中呢?今天我们就从这个问题开始来聊一聊索引和慢查询。

另外插入一个题外话,个人认为团队要合理的使用ORM,可以参考 ORM的权衡和抉择。合理利用的是ORM在面向对象和写操作方面的优势,避免联合查询上可能产生的坑(当然如果你的Linq查询能力很强另当别论),因为ORM屏蔽了太多的DB底层的知识内容,对程序员不是件好事,对性能有极致追求,但是ORM理解不透彻的团队更加要谨慎。

案例剖析

言归正传,为了实验,我创建了如下表:

CREATE TABLE `T`(

`id` int(11) NOT NULL,

`a` int(11) DEFAUT NULL,

PRIMARY KEY(`id`),

KEY `a`(`a`)

) ENGINE=InnoDB;

该表有三个字段,其中用id是主键索引,a是普通索引。

首先SQL判断一个语句是不是慢查询语句,用的是语句的执行时间。他把语句执行时间跟long_query_time这个系统参数作比较,如果语句执行时间比它还大,就会把这个语句记录到慢查询日志里面,这个参数的默认值是10秒。当然在生产上,我们不会设置这么大,一般会设置1秒,对于一些比较敏感的业务,可能会设置一个比1秒还小的值。

语句执行过程中有没有用到表的索引,可以通过explain一个语句的输出结果来看KEY的值不是NULL。

我们看下 explain select * from t;的KEY结果是NULL

explain select * from t where id=2;的KEY结果是PRIMARY,就是我们常说的使用了主键索引

explain select a from t;的KEY结果是a,表示使用了a这个索引。

虽然后两个查询的KEY都不是NULL,但是最后一个实际上扫描了整个索引树a。

假设这个表的数据量有100万行,图二的语句还是可以执行很快,但是图三就肯定很慢了。如果是更极端的情况,比如,

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值