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

这条语句MySQL也没有改写成功 [image]

[image] MySQL 自动改写了

按region 去拿的

ticdc 在某些场景下会初现ddl 乱序，导致报错 6.5版本

第二个我看 pr 合并到 master 了，老版本没合，这个主要说的是算子实现不够高效的问题，你纠结的不是执行计划的问题吗 都有哈哈，感谢老师回复

是的，但是不知道在oracle 这种成熟的数据库上是否能够做到，请老师指教

1.我的个人想法是回表的代价很巨大，像tidb 这种这种lsm存储引擎数据库的代价比传统类mysql的数据库回表的代价更大，但是这里还是选择走index join ，似乎对于这部分成本的评估不是很精确 2.semi join 应该是没做优化的，可以看下这个帖子 子查询重复值多的情况下半连接执行太慢 感谢老师回复

[image] 我说的是这种形式的优化，也不知道我的理解有没有问题 https://dev.mysql.com/doc/refman/8.0/en/semijoins.html

谢谢老师的回复

试试tiflash，飞一般的速度

大佬，请教1个问题 ，安装官网对于子查询的优化 [image] 子查询 select * from t1 where t1.a in (select t2.a from t2) 会被改写为 select t1.* from t1, (select distinct(a) a from t2) t2 where t1.a = t2.a 那么t2只能当驱动表？不能当被驱动表？我觉得应该可以把，我记得MySQL可以

是我误解了，当然我说的不是某个特定的连接算法，我这里有点记忆错了 感谢大佬，解决我的疑问，子查询的那个优化，其它数据库也是有的，感谢

2.这个是因为它是 index hash join 的 build 端。 那它应该显示再Indexhashjoin 后面把

是的。tidb的执行计划对于build和probe 显示确实有点乱

1.第2条语句多了个子查询，从实现来说，多了个join，等于是3个表Join，既然是3个表关联，肯定会存在先2个表关联，然后再和剩下的表进行关联 2.语句，t和t2表走的IndexHashJoin的，然后再和 WIND_TB_OBJECT_6757_OPLOG 走了个 hash join 关键就在于t2为什么进行了个全表扫描，但是你提供的信息是不完整的，所以看下t2的过滤条件字段是否有索引呢或者选择性怎么样呢 [image]

mysql> explain analyze select * from customer where C_CUSTKEY in (select C_CUSTKEY from tempcustomer limit 1); +--------------------------------+---------+---------+-----------+--------------------+----------------------------------------------------------------------------------------------------…

目前来说，应该是找到初步的原因了 node_exporter采集的数据是从/proc/meminfo 里面获取的，发现proc/meminfo 里面的SReclaimable 占用很大（大概50G），而Cached 占用很少，所以怀疑是有可能发生了操作系统内存泄露

那是numa node的信息 总体的内存使用率在 /proc/meminfo中获取