要这么办嘞
手动更新统计信息
使用ANALYZE TABLE 命令来手动触发统计信息的搜集
这个确实是个临时的解决办法。我刚刚看了下这个表的执行计划，还是10行 对应 70w，经历了一天的时间，为啥tidb没有自动给我重新收集一下统计信息呀，我有点迷惑
可以通过 SHOW STATS_HEALTHY 来查看 Healthy 字段，一般该字段值小于等于 60 的表需要做 analyze。
我刚看了下，我这个业务系统有八百多个表的这个值为0，怎么这么多？我要是手动去analyze，那是不是不太现实。而且有些表数据的增速在某一刻可能很快，对于这种表有没有什么好的解决方案呀
准确来说八百多个0或小于60的
你触发自动统计信息收集的阈值是不是太高了？我记得TiDB默认是0.5，我们生产一般都调小为0.1。
可以查下你们是否有统计信息收集失败了
还有你上面的执行计划里走的索引是单列索引还是联合索引？是你索引字段的区分度不够吗？如果是单列索引，可以考虑建联合索引（区分度高的字段放在前面）。这索引扫描和回表的数据量都有70万了，肯定会比较慢。
解决了吗？索引怎么建的，换了组合索引后有改善吗
做个表有五十多个索引，至于查询条件中的item_type_id 是独立普通索引，然后 id 是主键
这个要怎么查？
还没试，这个表的结构不是我一个人能决定啊
可以查下这张表 mysql.analyze_jobs
https://docs.pingcap.com/zh/tidb/stable/information-schema-analyze-status
这个表有50多个索引，有点多了，看看是否有些索引是否是冗余的，还有是否有些索引根本用不到；索引太多，未必是好事，比如对写入速度而言就有比较大的影响；把有用的复用性高的索引留下才是关键。
那你们tidb_auto_analyze_ratio使用的是默认的0.5，我们生产设置的是0.1，相对来说自动收集统计信息触发的概率会更高一点，收集更加频繁一点。
好的，我设置一下
多谢解答
