【 TiDB 使用环境`】生产环境
【 TiDB 版本】4
【遇到的问题】有一张查询机器表(host,约6万多条数据),38个or 查询条件拼接起来,性能很慢，查询时间约1.4秒。导入到mysql执行执行0.1秒。对host表做了表分析之后,性能无变化。最后重建了host后,查询正常，耗时0.1秒
【复现路径】无
【问题现象及影响】
【附件】
当时执行计划以及健康度是否有？
这个执行计划是走了全表扫描，没有使用索引
- 这个表是否有有效的索引
- 当时是否检查了索引的健康度
无索引，一直都是走的全表扫描。数据量不大。正常情况下走全表扫描也不会耗时那么长
看执行计划，这个sql只用了260ms，这个表有大量delete或者update吗
没有，表重建了一下，就恢复正常了
切断业务流量，重启tidb，tikv节点后，还是一样，也不是其他sql影响了
有两次sql的执行计划的对比图吗
explain analyze 一下两个执行计划
见上图，host_tmp 是原来表rename过去的
SHOW STATS_HEALTHY 看下两个表的健康度
analyze ，重新收集统计信息试试
能把完整的explain analyze 发一下吗 看下是否是算子下推失败
上面回复里有
之前有做表分析，没效果
修复前的执行计划中，绝大多数时间消耗都在tikv_task中，可以判断是当时的tikv过慢的问题。如果要继续分析，需要拿到慢日志的信息才可以了。
旧表 regions 个数只有一个？新表有多个？
可以通过 show table t_old(t_new) regions 查看一下。
如果以上验证成立，那么结果就符合预期，因为多个 regions 可以并发执行，自然就快。
“重建了host后” 是怎么重建的导致两个 regions 个数差别这么多？
表数据量有多少？
https://docs.pingcap.com/zh/tidb/stable/manage-cluster-faq#如何预估-tidb-中一张表的大小
1 个赞
