【 TiDB 使用环境】生产环境
【 TiDB 版本】7.1.5
背景：
原6.1.5 迁移至7.1.5后
部分查询出现索引失效，重新analyze之后恢复正常， 但是间隔几个小时，又出现了。表的健康度排查都是99，这是新版本的bug吗？
分析前
explain analyze
分析后
建议你把问题分类改成产品缺陷，会有产研人员跟进
确实，没有遇到过索引反复失效的
好的列。 这个问题比较蛋疼，
绑定下执行计划那，有用吗
绑定执行计划吧。
你试试将 join reorder 优化关掉试试：https://docs.pingcap.com/zh/tidb/stable/join-reorder
session 级别关掉之后 测试下 看看。
这个表经常做哪些操作？ sql中的时间条件范围是多少 每次如何变化？下次失效可以抓下信息
https://docs.pingcap.com/zh/tidb/stable/sql-plan-replayer#使用-plan-replayer-capture-抓取目标计划
是时间字段上的索引？
SQL条件一样吗
时间字段上的索引，但是查询条件一直是在变化的吧，例如每次查询都是查询15分钟内的数据，这时，如果表的统计信息是15分钟之前的，就可能使用不到索引，所以建议sql指定hint，或者绑定执行计划。
有子查询，没有办法绑定执行计划
sql发一下
select CoreVer,Chl,CoreVer2,Chl2,AppVer,Idfa,Mt,CreateTime,Id,Ip,LastLoginTime as RowUpdateTimestamp,RegCountry,UniqueCdReaderId from tidb_cdc_en.AccountInfo where mt = 4 and idfa <>‘’ AND LastLoginTime > DATE_ADD(now(),INTERVAL -24 HOUR) AND UniqueCdReaderId IN(select UniqueCdReaderId FROM tidb_cdc_en.log_installreferrerlog where createtime > DATE_ADD(now(),INTERVAL -4 HOUR) AND createtime < DATE_ADD(now(),INTERVAL -10 MINUTE) AND Mt = 4 AND UacStatus = 0);
先改成这样试一下能走索引吗？
select /*+ USE_INDEX(t1, ix_LastLoginTime) */CoreVer,
Chl,
CoreVer2,
Chl2,
AppVer,
Idfa,
Mt,
CreateTime,
Id,
Ip,
LastLoginTime as RowUpdateTimestamp,
RegCountry,
UniqueCdReaderId
from tidb_cdc_en.AccountInfo t1
where mt = 4
and idfa <> ‘’
AND LastLoginTime > DATE_ADD(now(), INTERVAL - 24 HOUR)
AND UniqueCdReaderId IN
(select UniqueCdReaderId
FROM tidb_cdc_en.log_installreferrerlog
where createtime > DATE_ADD(now(), INTERVAL - 4 HOUR)
AND createtime < DATE_ADD(now(), INTERVAL - 10 MINUTE)
AND Mt = 4
AND UacStatus = 0);
TiDB有查询计划缓存机制，如果某个查询首次执行时选择了不理想的计划，这个计划可能被缓存并重复使用。你可以尝试调整查询计划缓存的相关参数，如plan-cache-enabled 和plan-cache-evict-ttl ，或者在遇到性能问题时手动清空缓存（尽管这通常不是长久之计）。