应该是7.1.2这版有bug ，用了7.5.1版导入，顺便把集群升级了

经过 @小龙虾爱大龙虾 讲解下理解了这个执行计划： 在tidb中 处理非关联子查询时先进行预处理，变成一个常量，tidb的执行计划展示对于这种子查询预处理时如果返回是false则执行计划中会显示dual ，如果为真的话则不展示子查询相关的内容， 实际执行计划中的索引扫描不是子查询的执行计划，这里展示的是外层查询的计划。 当为true时(如没有其他条件)可能就是个全表扫描 tidb做了优化选择了一个kv最短的索引来执行。

对他这个就是 id=4中每一行驱动子查询，咱先不看他这个咋驱动的，就先看他对子查询的处理，是用了我觉得正确的索引

这是友商库的执行计划，他就走对索引了 KEY TI_O_CREDIT_STOP_OPEN_WP_5_USER_ID_IDX (USER_ID,IS_WP_FINISHED) ，先不看他整体计划 [image]

但是执行计划1 3选的不是最优执行计划。

都是预处理，那就都是先执行子查询对吧，这个子查询先单独执行那肯定 (USER_ID ,IS_WP_FINISHED ) 是最优的，单独explain analyze也是这样 ，不管这个子查询结果返回是true还是false ,肯定是要执行子查询做扫描吧

执行计划2是预处理了，那执行计划1、3是预处理吗？

[image] 子查询单独执行索引是没问题的，用字符串也是正确索引 [image]

这个可以想明白，问题是 他在判断true 和false时应该走哪个索引是最优的，他总得要找下有没有user_id这个数据吧

执行计划2 有dual了是看不到了，那么执行计划1、3 就不进行预处理了吗？如果预处理了 先执行了子查询那么走的索引肯定就是不对的。 如果limit 没有推到子查询里 并且子查询有了预处理，那么执行计划3的limit 为什么下推到索引扫描了？ 还是说内部把这个not exists+子查询进行了SQL转化后生成的执行计划。

子查询里加hint 也是一样的

1、 这里的逻辑是子查询预处理生成一个常量 判断真假，在子查询预处理时把limit 1代入到子查询了 ？但是无论如何子查询处理时还是走(USER_ID,IS_WP_FINISHED)更合适吧，走其他索引至少要从索引里找到一个user_id符合的或者扫描完找到不符合的才行吧 2、我前面发的另一个帖子链接 就是unionscan时 topn算子没有下推tikv

这个单独看是正常的

1、 看了下影响行数，dual的确实是0条数据的，0条数据得写需要扫描索引或表才能确定，应该也展示如何扫描的，为何展示为dual , 毕竟这不是一个SQL条件一看就不成立的情况。 2、 这种id列直接走对应索引 怎么也会比走个不相关索引的index full scan扫描的要少吧？

问题已解决，原因是主机添加防火墙，只允许集群内的主机访问23792端口 漏掉了151这个节点自身IP的配置，导致本节点不能访问 ，而其他pd节点可以访问该节点，感谢 @小龙虾爱大龙虾 @WalterWj 大佬 [image]

diag-btjh-gnZWsm3Qd4F.tar.gz (23.7 MB)

这个时间应该是我手工拉起集群的前后，开始的时候先start的一直不行，看了pd的进程还在(151节点的没看)，就stop cluster后又start才起来的，之后扩容了一个pd。 151:28792这个原来的pd就一直起不来，昨晚22:16的时候pd日志开始有报错，之前是151节点是leader [image]

curl http://10.172.65.146:23802/members [{“id”:9357444448847789453,“peerURLs”:[“http://10.172.65.152:23802”],“name”:“pd-10.172.65.152-23792”,“clientURLs”:[“http://10.172.65.152:23792”]},{“id”:11468259817903508096,“peerURLs”:[“http://10.172.65.151:23805”],“name”:“pd-10.172.65.151-23795”,“clientURLs…

网络当时没看 ，如果是网络问题当时导致down了后，为啥后面151这个节点的拉不起来了