mysql limit by_关于MySQL where .... order by .... limit 1性能问题和解决办法

小伙伴们估计遇到过在数据量超过几十万的时候使用where .... order by .... limit 1这样的语句,花费的时间比where .... order by ....还要慢,这是为什么呢?

开始我也不知道为什么,网上找了很多,发现不少人遇到了这样的问题,按照我们正常的逻辑思维,这条语句执行应该是先使用order by 的索引,然后使用where 条件,最后在截取一条返回给我们是不是?然而并不是如此,下面我以项目中的数据来测试

75b1827a2a0b

总数

我们数据在百万这个级别,OK我们使用where .... order by .... limit 1这样的语句来看看效果

75b1827a2a0b

直接执行的效果

这样一个查询花费了19秒,对于我们线上业务来说是不能够接受的,我们尝试去掉limit呢

75b1827a2a0b

不使用limit

一看吓一跳是不是,居然用了limit时间还多花费了几十倍,我们使用EXPLAIN(不知道这个的同学可以单独百度一下)来检查一下这两条sql

75b1827a2a0b

EXPLAIN分析使用limit

75b1827a2a0b

EXPLAIN分析不使用limit

区别很大是不是,使用limit虽然类型是index而且可能用到bookId索引,结果直接就是使用的where;而没使用limit的时候类型是ref,结果是使用了条件索引bookId和文件索引,具体的原因我没有深入去寻找答案,但是我猜测应该跟mysql内部优化算法有关系,不纠结这个,我们先说说怎么去解决这个问题,感兴趣的可以自行google

不走索引?那我们就让他强制索引force index

75b1827a2a0b

强制索引

75b1827a2a0b

EXPLAIN分析强制索引

哇塞效果很理想嘛,跟不使用limit的差不多,而且只返回一条,but难道以后我们都要自己去添加强制索引吗?然后捉摸着我找到了另外一种迂回的方式,如下

75b1827a2a0b

迂回

75b1827a2a0b

EXPLAIN分析迂回

看起来确实很迂回,但是我们确实不需要强制指定索引了,让mysql自己选择最好的索引吧 哈哈

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值