sql执行计划走了错误的索引

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
tidb 5.4.0 ,centos 7.5

【概述】 场景 + 问题概述
tidb近期升级到5.4.0,发现总是走错误的索引,每次手动解析后就会变好,但是过一段时间又会走错误的索引

dashboard执行计划,走了错误的索引

执行时间2.4秒

表的健康度

表的索引结构

手动解析后,瞬间执行完成

手动解析后,执行计划走了正确的索引

统计信息版本为1,我们是刚刚从4.0.13升级到5.4.0的

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题
请问有什么方法可以解决这个问题,谢谢

【业务影响】

【TiDB 版本】

【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

我觉得有两种方法
1、绑定执行计划:
https://docs.pingcap.com/zh/tidb/v5.4/sql-plan-management#执行计划绑定-sql-binding
2、在这条sql中用hint强行走指定索引:
Optimizer Hints | PingCAP Docs

优化器之所以倾向于选择时间字段索引,估计是因为你where条件里面时间范围区间在统计信息记录的范围之外了,统计信息永远是旧的。例如统计信息记录的是昨天以前的数据,你sql里写了个今天的时间范围,那优化器根据统计信息就认为你这个sql里时间范围上是没有数据或者非常少数据的,因此走时间范围索引筛选能力就非常强。
1、建议删除手机号字段上那个索引,创建(手机号,时间)联合索引,减少优化器的选择索引的顾虑
2、试一下v2版本的统计信息看能否改善
3、绑定执行计划或force index

1赞

1、可以先手动绑定执行计划,但是这个只能对已知的sql进行;
2、hint 强制索引的话:对于程序生成的sql不方便修改,即使可修改需要业务重新配置,存在有一定的风险

个人觉得可以分析一下sql,看看索是否是最优的,尤其复合索引

已经改成v2版本了,再观察下,还不行的话,就改索引,多谢!

analyze version最好别设置成2,因为可能触发OOM的bug。

OOM这个在5.4还没有修复吗

:joy: 我记错了,刚刚去问了一下,这个bug在5.3以后修复了。

今天早上又出现了,改成v2版本也不行,准备用联合索引的方式

联合索引应该是可以解决的了,建议先创建联合索引,再删除单列索引,避免中间没有索引可用