首先，作为MySQL的资深用户，却来作为MySQL 8.0 主打功能hash join的“短”，实在对不住MySQL产品， 但该问题确实比较严重，所以也希望更多的人熟悉这个缺陷，避免踩坑或者掉到坑里还不知道怎么回事，更希望有能力的专家来修复这个缺陷。
为了不耽误大家时间，将把问题描述得尽量简单。用下面SQL创建3个表，再各插入一条记录，然后做三个表之间的关联：
create table t1 ( t1_id varchar(20),t1_name varchar(20) ,t1_addr varchar(20));
create table t2 ( t2_id varchar(20),t2_name varchar(20) ,t2_addr varchar(20));
create table t3 ( t3_id varchar(20),t3_name varchar(20) ,t3_addr varchar(20));
insert into t1 values('a','a','a');
insert into t2 values('a','a','a');
insert into t3 values('a','a','a');
我们来分析这三个表的关联SQL的执行计划：
explain format=tree select * from t1,t2,t3 where t1_id=t2_id and t2_addr=t3_addr ;
SQL的意思很简单，T1与T2关联，然后再跟T3关联。SQL的执行计划也如下， 跟我们预期的一样，先访问T1,然后关联T2,再关联T3. 因为表没有索引，所以采用了mysql 8.0的新功能hash jion 做关联。
如果真的只会出现本来应该的出现的，理所当然的，一定合理的关联顺序，那就不会有这个小文章。
下面我们来制造问题。 手段很简单，将T2表再插入10条记录。SQL如下。
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
insert into t2 values('a','a','a');
我们再来看执行计划：关联顺序变成了T1->T3->T2. 但where 条件中表T1跟表T3的字段之间有直接的等于关系吗？没有， 那它两做关联后的产生结果是什么？将产生笛卡尔积数量的临时结果，会消耗大量的空间跟cpu.（细心的朋友可以发现，图片中划线的部分，相比之前的执行计划，少了等于条件，这就是在做笛卡尔积关联）
为什么对T2表多插入几条数据，执行计算就变了？ 目前简单地猜测（纯属肤浅猜测，还没有做源码级研究），mysql做hash jion 的时候， 只看表的数量，小表在前，大表在后，因为T2表的数量最多，所以放在最后，而让没有直接等于关系的T1表跟T3表去做笛卡尔积关联。如果T1跟T3表各有10万条记录，则产生100亿条的临时记录，然后再去跟T2表进行关联，产生的后果,，，，，，想想就觉得恐怖。
希望&拜托看到这个问题的专家能够及时贡献自己的力量，为广大用户谋福利。如果这个问题没有解决，8.0的hash jion远远谈不上是一个可以放心使用的功能。该缺陷在8.0.19版本跟8.0.18版本均存在（更低版本没有测试） ，真的非常希望在下一个版本，这个缺陷就可以消失。