为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【概述】 场景 + 问题概述
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 小时日志）
若提问为性能优化、故障排查 类问题，请下载脚本 运行。终端输出的打印结果，请务必全选 并复制粘贴上传。
优化器之所以倾向于选择时间字段索引，估计是因为你where条件里面时间范围区间在统计信息记录的范围之外了，统计信息永远是旧的。例如统计信息记录的是昨天以前的数据，你sql里写了个今天的时间范围，那优化器根据统计信息就认为你这个sql里时间范围上是没有数据或者非常少数据的，因此走时间范围索引筛选能力就非常强。
1 个赞
1、可以先手动绑定执行计划，但是这个只能对已知的sql进行；
个人觉得可以分析一下sql,看看索是否是最优的，尤其复合索引
已经改成v2版本了，再观察下，还不行的话，就改索引，多谢！
analyze version最好别设置成2，因为可能触发OOM的bug。
今天早上又出现了，改成v2版本也不行，准备用联合索引的方式
联合索引应该是可以解决的了，建议先创建联合索引，再删除单列索引，避免中间没有索引可用
添加联合索引后，这几天没再出现这个问题，大神多谢了
请问你的手机为什么是字母字符串？应该是阿拉伯数字吧？
这个得看他应用怎么设计的，另外如果考虑到跨国号码，前面要有加号
system
2022 年10 月 31 日 19:26
16
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
我记错了，刚刚去问了一下，这个bug在5.3以后修复了。