加个!不行的，else 也可以但这是绕过去

发个完整的执行计划？

好的，多谢

将~/.tiup/storage/cluster/clusters 目录下面以集群命名的目录 放到~/.tiup/storage/cluster/clusters 下面就可以了

也不行，这个只是显示功能而已

没有了

和这个没关系的,到了MySQL 8.0 没有说的你那个特性

但是为什么要对gender 排序呢，应该是对age排序才对

企业版支持？有说明或者测试结果嘛

优化器这块还是需要继续加强

不知道为什么 hash join 后要形成笛卡尔积，这种在Oracle 上好像不需要形成笛卡尔 集合

是的，我就是这个意思 所以我才觉得tidb 那里的又多判断了一次 [image]

我的意思是语句的join 的时候 a和c的join 条件为a.c1 = c.c1 and a.id = c.id 然和和b表去关联是b.id=c.id 是这个意思

[image] 为什么从这里得到的测试结果是a和b先join，再和cjoin 6.5.3版本

1.从MySQL和PG的测试来看，都支持自动推到出来a.id=c.id [image] [image] 2.有个疑问？ [image] a和c表关联后，再和b表关联，应该只需要满足b.id = ``c.id` 就行了吧或者b.id=a.id 不需要 eq(test.a.id, test.b.id) eq(test.c.id, test.b.id)] 这两个条件同时去判断了吧？

应该是bug来着，6.5.6以上的版本应该修复了 也可以通过下面这种方式绕一下 select /*+hash_join_probe(q) */ q.a,q.b from ( select a,b from table1 partition(p0520) where c >100 group by a,b) as n join table1 partition(p0520) q on n.a=q.a group by a,b;

谢谢，这可能只是一种绕过的方法

q,b这里只是我写错了，就是q.b

在实践使用中我们也发现了这个问题，如果 TiCDC 同步流有延迟，出现重启（手动调参重启或任务自动重启）时，会有很高的瞬时 CPU 冲击，如之前遇到的一个案例在同步任务的延迟超过 20 小时后，手动重启同步流，瞬时消耗 CPU达到了 6000%（共8000%）。此时可能会带来一些额外问题，如果是和其他节点混部，可能会对集群产生冲击。 这也说明在极端场景，尤其是延迟接近 24h （GC safe point TTL）时，重启同步流会有很夸张的 CPU 瞬时冲击。这是因为 TiCDC 重启后需要重新全部获取落后的数据，重新进行落后这段时间内的变更数据拉取、排序和同步。 延迟越高，同步流重启时…