第二个我看 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中获取

补充下: 1.free -h 里面显示的buffer/cache 显示有57G 2.node_exporter显示的node_memory_Cached_bytes 只有8G 3.怀疑是node_exporter采集错了或者是buffer 占用过大，cache占用过小，这个下星期登录下服务器看下/proc/meminfo 里面的具体Buffer和cache的值 各占多少

分配的内存应该就是已经正在的使用的内存，包括buffer/cache

C_CUSTKEY 是customer的主键索引

mysql> explain analyze select /*+ INL_JOIN(customer,orders) */ count(*) from customer where exists (select orders.O_CUSTKEY from orders where customer.C_CUSTKEY=orders.O_CUSTKEY); +-------------------------------+-------------+----------+-----------+--------------------------------------------…

[image] wo我执行计划里面都出现了merge join