mysql limit导致索引选择(选择的并不是最佳索引)的处理方案

昨天公司APP项目上线时遇到一个奇葩问题,在这里简单做一个记录,以避免如果再遇到类似问题再去花费时间寻找解决方案。

首先贴出cp_orders表中建立的索引

使用限制符limit时,mysql使用了idx_order_type索引,扫描了46w行

没有使用限制符limit时,mysql使用了idx_agent_order_type索引(联合索引),扫描了9k行

解决方案:

1.order by a.`code`+0 DESC,mysql会使用idx_agent_order_type索引

2.cp_orders a FORCE INDEX(idx_agent_order_type),强制使用idx_agent_order_type索引

3.延迟关联查询

问题追踪:

1.cp_orders表索引过多

2.mysql优化器内部bug(详细请参阅:https://yq.aliyun.com/articles/51065

bug 触发条件如下:

  1. 优化器先选择了 where 条件中字段的索引,该索引过滤性较好;
  2. SQL 中必须有 order by limit 从而引导优化器尝试使用 order by 字段上的索引进行优化,最终因代价问题没有成功。
  • 2
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 6
    评论
评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值