Binding还不如hint，起码业务行为发生变化，研发可以感知。用了binding，时间久了可能都不知道这个binding是基于什么原因加上的。这个是作为应急的兜底方案，而且应该做成临时方案，应用加上hint后去掉binding。

这是一种无奈之举，目前的解决方法，对开发人员来说比较痛苦，开发更应该关注业务而不是怎么加hint，很多场景下也不好添加。

楼上各位说了这么多也没有举出说这个子查询最佳实践规则是错误的点，请举出反例，让我更好的总结问题。 数据库优化是一个复杂的过程，不能说复杂就只想着只有上了生产看到执行计划再调优（而且你不知道最佳实践可能也不知道怎么优化），那就出问题了。还是要总结出最佳使用方式，尽量避免踩坑，按照最佳时间来让多数情况下获得更好的结果就可以了。

明白，受教了！

根据你这个例子，猜测外表是大表，子查询内表是小表，关联结果是小结果集，套用上面这个规则逻辑看看是不是有更好的执行计划？

不是binding语法，是这个hint怎么写呢？

请教下，怎么绑定？

非重复执行一般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，本身自己程序逻辑就存在问题吧。