我看最新的帖子里面有提到健康度太低也可能出现全部走tikv而导致耗时过长的?
这个执行从超长的sql的执行计划有嘛?
这是个bug的话,现在也挺难复现的。
如果方便可以考虑保存一下执行现场的信息。
https://docs.pingcap.com/zh/tidb/stable/sql-plan-replayer
可能有助于定位这个问题。
Dashboard 中的慢查询看下吧,是否有资源管控相关信息。
重启了服务器就没了吧?
看不了web😂
不能复现的bug,那就只能随缘了。下次出的时候尝试一下是否有机会。
现在应该已经更新了吧
现在在等8.1更新了
还有执行数据迁移的时候报
TiKV stores (1) contains more than 1000 empty regions respectively, which will greatly affect the import speed and success rate
这个怎么调呢
最近比较稳定了,多个大表join禁止全表查询耗时就少些了
1 个赞
可以通过 INFORMATION_SCHEMA.RUNAWAY_WATCHES 看下你这条 sql 还是否在runaway 列表里
空region相关的问题,你可以看看这个帖子。
建议升级到最新的tidb版本试试。
1 个赞
升级最新版本的tidb还是出现相同的问题,初步判断是表的统计信息有问题,导致选择了错误的执行引擎
在对表进行analyze操作后,几个表的健康度为100,执行sql的耗时又变少了
实际上几张表都是有用dm在实时同步数据,可能这样会导致健康度下降
我是否可以设置定时任务去执行analyze操作呢
更新个版本
已经是8.1.0了
mark学习一下
最近有复现bug,我判断是选择错了执行引擎