首先提出一个不相关的IN子查询
SELECT * FROM s1 WHERE key1 IN (SELECT common_field FROM s2 WHERE key3 = 'a');
对于不相关的 IN 子查询来说，如果子查询的结果集中的记录条数很少，那么把子查询和外层
查询分别看成两个单独的单表查询效率还是蛮高的，但是如果单独执行子查询后的结果集太多的话，就会导致这
些问题：
无法有效的使用索引，只能对外层查询进行全表扫描。
在对外层查询执行全表扫描时，由于 IN 子句中的参数太多，这会导致检测一条记录是否符合和 IN 子句中的参数匹配花费的时间太长。
比如说 IN 子句中的参数只有两个：
SELECT * FROM tbl_name WHERE column IN (a, b);
这样相当于需要对 tbl_name 表中的每条记录判断一下它的 column 列是否符合 column = a OR column= b 。在 IN 子句中的参数比较少时这并不是什么问题，如果 IN 子句中的参数比较多时，比如这样：
SELECT * FROM tbl_name WHERE column IN (a, b, c …, …);
那么这样每条记录需要判断一下它的 column 列是否符合 column = a OR column = b OR column = c
OR … ，这样性能耗费可就多了。
所以提出一个解决方案：不直接将不相关子查询的结果集当作外层查询的参数，而是将该结果集写入一个临时表里。
临时表的特性：
当我们把子查询进行物化之后，假设子查询物化表的名称为 materialized_table ，该物化表存储的子查询结果集的列为 m_val ，那么这个查询其实可以从下边两种角度来看待：
SELECT * FROM s1 WHERE key1 IN (SELECT common_field FROM s2 WHERE key3 = ‘a');
从表 s1 的角度来看待，整个查询的意思其实是：对于 s1 表中的每条记录来说，如果该记录的 key1 列的值
在子查询对应的物化表中，则该记录会被加入最终的结果集。画个图表示一下就是这样：
从子查询物化表的角度来看待，整个查询的意思其实是：对于子查询物化表的每个值来说，如果能在 s1 表
中找到对应的 key1 列的值与该值相等的记录，那么就把这些记录加入到最终的结果集。
也就是说其实上边的查询就相当于表 s1 和子查询物化表 materialized_table 进行内连接：
SELECT s1.* FROM s1 INNER JOIN materialized_table ON key1 = m_val;
如果使用 s1 表作为驱动表的话，总查询成本由下边几个部分组成：
如果使用 materialized_table 表作为驱动表的话，总查询成本由下边几个部分组成：
到此这篇关于Mysql查询优化之IN子查询优化方法的文章就介绍到这了,更多相关Mysql IN子查询优化内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
编程 | 2023-02-24 21:36
编程 | 2023-02-21 12:51
编程 | 2023-02-21 12:47
编程 | 2023-02-21 00:15
编程 | 2023-02-21 00:08
编程 | 2023-02-20 21:46
编程 | 2023-02-20 21:42
编程 | 2023-02-20 21:36
编程 | 2023-02-20 21:32
编程 | 2023-02-20 18:12
Python之列表推导式最全汇总(上篇)
加载中,请稍侯......
网友评论