MySQL在优化涉及相关子查询或子选择的查询方面存在已知问题。在5.6.5版之前，它不会具体化子查询，但是将具体化联接中使用的派生表。
从本质上讲，这意味着当您使用联接时，第一次遇到子查询时，MySQL将执行以下操作：
SELECt pre1 FROM myTable GROUP BY pre1 HAVINg COUNT(pre1) > 1
并将结果保存在临时表中（将其哈希处理以加快查找速度），然后
myTable针对临时表中的每个值进行查找，以查看代码是否存在。
但是，由于当您使用
IN子查询时，该子查询并未实现，而是被重写为：
SELECt t1.pre1, t1.pre2FROM myTable t1WHERe EXISTS ( SELECt t2.pre1 FROM myTable t2 WHERe t2.Code1 = t1.Code1 GROUP BY t2.pre1 HAVINg COUNT(t2.pre1) > 1 )
这意味着，对于
prein中的每个
myTable，它将再次运行子查询。当您的外部查询非常狭窄时，哪种方法比较好，因为只运行几次子查询比对所有值运行它并将结果存储在临时表中更为有效，但是当您的外部查询很宽时，它会得到结果在内部查询中执行了很多次，这就是性能差异的所在。
因此，对于您的行数，您无需运行子查询约30,000次，而是运行一次，然后在仅包含400行的哈希临时表中查找约30,000行。这将导致如此巨大的性能差异。
在线文档中的这篇文章更深入地解释了子查询优化。
