为什么说在SQL中将IN子查询重写为INNER JOIN能提升性能？-SQL-PHP中文网

IN子查询触发DEPENDENT SUBQUERY是因为外层每行都重复执行子查询，且MySQL无法物化结果、缺乏索引或存在隐式类型转换；改用INNER JOIN可一次性物理连接并利用索引下推，但需确保关联字段有索引、过滤条件写在ON子句、必要时加DISTINCT；临时表方案更稳定，须建主键、分批插入、避免MEMORY引擎处理字符串ID；优化后务必用EXPLAIN验证key非空、type非ALL或DEPENDENT SUBQUERY。

为什么说在sql中将in子查询重写为inner join能提升性能？

IN子查询为什么会触发DEPENDENT SUBQUERY

当EXPLAIN显示type为DEPENDENT SUBQUERY，说明外层每查一行，子查询就被重复执行一次。10万行主表 × 平均5ms子查询 = 500秒。这不是慢，是不可用。

根本原因在于MySQL无法物化该子查询结果，又没索引可用——比如SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE city = 'Shanghai')，若customers.city无索引，子查询就全表扫；若orders.customer_id类型是VARCHAR而customers.id是INT，隐式转换直接让索引失效。

INNER JOIN如何绕过重复执行

JOIN把“逐行判断存在性”变成“一次性物理连接”，优化器能选择hash join或index nested-loop，关键前提是关联字段有索引。

子查询结果被当作临时驱动表（如customers），主表orders走ref或range扫描
过滤条件必须下推到ON子句：写成INNER JOIN customers c ON o.customer_id = c.id AND c.city = 'Shanghai'，而不是放在WHERE里——否则可能无法触发索引下推
如果原IN逻辑只关心“是否存在”，JOIN后必须加DISTINCT，否则一对多关系会放大结果集

为什么临时表+JOIN比硬拼IN列表更稳

应用层传5000个ID进WHERE id IN (1,2,3,...)，不只是慢：SQL解析开销大、可能超max_allowed_packet、优化器大概率放弃索引、执行计划无法复用。

正确做法是建带主键的临时表：

剧云

一款AI工具，主要用于专业、高效、安全的中文剧本在线创作与管理工具，适合需要提升相关任务效率的用户。

下载

CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY);
INSERT INTO tmp_ids VALUES (1),(2),(3),...;
SELECT t.* FROM target_table t INNER JOIN tmp_ids i ON t.id = i.id;

注意三点：PRIMARY KEY必须加（否则JOIN退化为嵌套循环）；INSERT按批≤1000行；字符串ID别用MEMORY引擎（max_heap_table_size容易爆）。