非重复执行一般1-3ms就可以了，你这个存在一些问题，需要排查下。

多次重复执行意义不大，走了缓存（copr_cache_hit_ratio=1）。 要多次带入不同的值，避免copr_cache_hit_ratio=1。

就你发的这一个执行计划来看应该不太具有代表性，这个里面耗时最多的是get_snapshot时间，应该当时raft租约到期等待选主过程。如果频繁的出现这种get_snapshot慢的情况，需要查看静默region是否被频繁的唤醒了，或者磁盘是否存在一些写入瓶颈等等。 最好多发几次explain analyze执行计划看看，主要瓶颈在哪里。一般情况下点查1-3ms能完成。

我上面步骤就一定可以复现的，刚才本来想写个更简单的“一键复现”的例子，但是我在测试过程中执行： ALTER RESOURCE GROUP default QUERY_LIMIT=(EXEC_ELAPSED='2ms', ACTION=KILL, WATCH=EXACT DURATION='10m'); 发现一直等待中： [image] [image] 卡主了，然后我用admin ddl cancel jobs杀掉这个任务后，发现一直处于canceling状态。 [image] 重启tidb-server节点也无效。 节点信息： [image]

只能重启临时解决，但是还会很容易复现。

简单看了下，当format=true_card_cost时应该是基于实际结果值算出来的。

一般是因为子算子存在并行，在上层算子计算时候会除以并行度，所以看起来上层算子cost更低。 另外这个true_card_cost应该是基于实际值计算出来的，不是估算值。

理应当是基于estRows算出来的，但是有一部分结合了实际的执行行为，但是这块具体我没有研究过。

控制能力不足：从测试来看，控制TP业务还可以，但是控制略带有AP查询（如排序，聚合等）的业务能力不足（不容易控制住），往往都是这种带有AP类的查询才导致的故障，如何理解资源管控 (Resource Control) 中的RU RU概念难以理解：线上运行后再根据运行调整RU，这个调整的归属很难把控，到底是运维层面的DBA调整还是开发人员调整？DBA不懂业务，容易出故障（比如遇到月批、秒杀日等资源占用会突增，控制了资源导致业务受影响，但是DBA不熟悉业务），开发人员不熟悉RU的概念基本也是放到最大来调整。 限流策略落地难：参考这里：Runaway Queries在故障处理情况下存在的问题 更…

在之前版本IndexJoin的innerSide不支持非DataSource的算子，这个在8.1版本修改了，新增了对Agg算子的支持，但还不支持其它算子（比如各种Join）。 因此对于a join (b join c)形式目前是不支持a indexJoin (b join c)的，可以支持(b join c) indexJoin a。 也就是join的innerSide不能是(b join c)。 可参考这里：指定INL_JOIN，但执行计划并不走 你用的8.1版本只支持了innerSide是Datasource和Agg算子，join类的还不支持：https://github.com…

truncate操作是同步操作。你不等truncate执行完就另外session执行load data，本身自己程序逻辑就存在问题吧。

tidb就算做mpp其实也是在tidb-server上做，不可能在tikv上做。

好的，感谢！

请教下，这个storage read batches（storage write batch）是和如下这个参数相关么： [image]

请教下，这里tikv的iters的行为和tidb侧的loop是一样的么？

还是应了那句话，只要想到的早晚会遇到，果然在目前生产上就遇到类似的问题了。在其它老牌数据库中迁移过来的存在较多这种关联字段中包含or条件的，在发帖子当时测试OB时候它的优化器就能做到改写。我们目前也只能通过人工改写的方式来进行优化，改写逻辑大体如下： select a.c1,b.c2 from a,b where a.c1=b.c1 or a.c2=b.c2 改为方式为： select a.pk,b.pk,a.c1,b.c2 from a,b where a.c1=b.c1 union select a.pk,b.pk,a.c1,b.c2 from a,b where a.c2=b.c2…

在数据库server中使用kill命令没问题，在客户端直接终止程序不行，之前提过需求，不过终于在7.5实现了。

在7.5之前版本，在客户端直接杀掉进程后会数据库还会继续完成语句。如果正在执行大事务， 如果是自动提交则会事务执行成功，如果非自动提交事务会rollback，锁会自动释放。 在7.5版本，客户端杀掉进程后，数据库直接终止，语句立刻被kill掉，事务会回滚，锁也会释放。 [image]