t.order_time BETWEEN ‘20250501000000’ AND ‘20250531235959’ AND t.agent_no_tree LIKE concat(‘101106,129456’, ‘%’); 这两个条件push down filter用哪个完全取决于你的统计信息里面哪个字段的过滤效果更好，没有应该走哪个更合理的说法。

tikv的话，优化大sql就行

tidb-server的话，你不连他不就相当于缩容了？或者把机器关了

看执行计划，走tikv确实比较合适啊，explain analyze实际执行下看看

https://docs.pingcap.com/zh/tidb/stable/tiup-cluster-topology-reference#monitoring_servers 参考这里面有配置，设置storage_retention storage_retention：Prometheus 监控数据保留时间，默认 “30d”

自动收集信息是单线程的，影响应该不大吧，如果统计信息不准对业务也有影响吧

近期令你印象最深刻的 TiDB 文章是？ 从40秒到11毫秒：TiDB环境下一次SQL深潜优化实战

正常就应该是老任务继续执行，不会启动新的收集统计信息的任务。

部署了8.5.2验证已经修复，可以的话，也可以升级集群到8.5.2

发布了啊，我刚才都部署测试了

看了下8.5.2已经修复了，可以的话，也可以升级集群到8.5.2

如果类似sql很多的话，只能先禁止topN下推临时解决下吧，但是对性能会有影响： INSERT INTO mysql.opt_rule_blacklist VALUES(‘topn_push_down’); ADMIN reload opt_rule_blacklist;

试一下禁止topN下推， INSERT INTO mysql.opt_rule_blacklist VALUES(‘topn_push_down’); ADMIN reload opt_rule_blacklist; 不过这个可能会对性能有点影响

这看着是个bug，子查询结合limit的bug，改成关联就没问题了，SELECT t1.NAME AS GenderName, t2.id AS SugarNav_Id, t2.gender_id AS SugarNav_GenderId, t2.account AS NAME, t2.id AS Id FROM t2 LEFT JOIN t1 ON t2.gender_id = t1.id ORDER BY t2.id ASC LIMIT 20, 20;

嗯，报错的store id应该是你报错的那两个，现在你已经有损恢复的3个store时没问题的，有损恢复完之后有重启集群吗？应该是集群里面还残存有原来的store信息

SELECT * FROM INFORMATION_SCHEMA.TIKV_STORE_STATUS;看下，或者进pdctl里面store看下

调整下 tidb_mem_oom_action和https://docs.pingcap.com/zh/tidb/stable/system-variables/#tidb_mem_quota_query变量吧

可以设置自动收集统计信息的并发度，https://docs.pingcap.com/zh/tidb/v6.5/system-variables/#tidb_auto_build_stats_concurrency-从-v650-版本开始引入，或者直接LOCK STATS 锁定你认为无需收集统计信息的临时表。 正常的表自动分析业务表是对的，tidb_auto_analyze_ratio这个参数就是用来控制多少数据变更才触发自动收集统计信息的，如果你的表数据变更比例过大，如果不自动分析，你的sql很大概率走错索引，引发数据库问题。

analyze explain看下实际的执行计划吧