MySQL查询语句中的IN 和Exists 对比分析(2)

使用exists时，数据量的变化没有带来执行计划的改变，但由于子查询结果集很大，5.5以后的MySQL版本在exists匹配查询结果时使用的是Block Nested-Loop（Block嵌套循环，引入join buffer，类似于缓存功能）开始对查询效率产生显著影响，尤其针对<font color=red>子查询结果集很大</font>的情况下能显著改善查询匹配效率：

实验结论

根据上述两个实验及实验结果，我们可以较清晰的理解IN 和Exists的执行过程，并归纳出IN 和Exists的适用场景：

IN查询在内部表和外部表上都可以使用到索引；

Exists查询仅在内部表上可以使用到索引；

当子查询结果集很大，而外部表较小的时候，Exists的Block Nested Loop(Block 嵌套循环)的作用开始显现，并弥补外部表无法用到索引的缺陷，查询效率会优于IN。

当子查询结果集较小，而外部表很大的时候，Exists的Block嵌套循环优化效果不明显，IN 的外表索引优势占主要作用，此时IN的查询效率会优于Exists。

网上的说法不准确，即表的规模不是看内部表和外部表，而是外部表和子查询结果集。

最后一点，也是最重要的一点：世间没有绝对的真理，掌握事物的本质，针对不同的场景进行实践验证才是最可靠有效的方法。

实验过程中发现的问题补充

仅对不同数据集情况下的上述exists语句分析时发现，数据集越大，消耗的时间反而变小，觉得很奇怪。
具体查询条件为：
where tp.poetry_id>3650，耗时0.13S
where tp.poetry_id>293650，耗时0.46S
可能原因：条件值大，查询越靠后，需要遍历的记录越多，造成最终消耗越多的时间。这个解释有待进一步验证后再补充。