mysql join 缺陷,MySQL 8.0 Hash Join 严重缺陷

首先，作为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版本均存在(更低版本没有测试) ，真的非常希望在下一个版本，这个缺陷就可以消失。