Join后执行过滤查询速度骤降10-15倍，原因何在？

核心执行逻辑差异 #

• 过滤Links表的场景：数据库会先对Links表应用child_item_id in (...)过滤，直接把数据集缩小到45000条左右的目标记录，再用这些精简数据关联父、子Items表。整个流程的基础数据量小，关联计算的开销极低。
• 过滤子Items表的场景：因为是left join，数据库会先执行全量关联——把所有父Items、所有匹配的Links、所有匹配的子Items拼接成一个超大中间结果集，之后再从这个大集合里筛选符合条件的行。如果原表数据量大，这个中间集的规模会是前者的数倍甚至数十倍，自然耗时剧增。

隐式的连接类型变更 #

原本的left join items child是左连接，允许父条目/Links记录在没有匹配子条目时保留。但加上where child.id in (...)后，child.id不能为null（IN列表全是有效ID），这相当于把左连接强制转成了内连接。但优化器可能没识别到这个逻辑，还是按左连接的流程先做全量关联，再过滤，没有提前缩小数据范围。

索引利用效率天差地别 #

• 针对l.child_item_id的过滤，数据库可以直接命中Links表上child_item_id的索引，瞬间定位到目标记录，效率拉满。
• 针对child.id的过滤，哪怕child表的id有索引，也得在关联后的临时大结果集里做匹配，索引的作用被大幅削弱，本质是在一个无索引的临时表上做查找，速度自然慢。

验证方法 #

查看两种查询的执行计划，重点对比：

• 第一步过滤后的Links表记录数
• 关联操作的输入数据集大小
• 索引的实际使用情况（是否用到child_item_id或child.id的索引）

内容的提问来源于stack exchange，提问作者Mcscrag