应谨慎用INNER JOIN替代IN子查询：仅当语义等价（如需关联取值而非仅存在判断）、结果可接受（注意一对多导致重复行）、执行计划改善且索引有效时才适用；否则优先选EXISTS或保持原写法。
能用 INNER JOIN 替代 IN 子查询，不等于应该无脑替换——只有当语义等价、结果可接受、且执行计划确实改善时才值得改。
确认业务逻辑是否允许 INNER JOIN 的语义
IN 子查询天然去重、只判断“是否存在”，而 INNER JOIN 会把主表一行展开为多行（一对多时）。比如：
- 原语句
WHERE user_id IN (SELECT user_id FROM orders WHERE status = 'paid')只关心“用户有没有付款订单”，结果里每个用户最多出现一次 - 改成
INNER JOIN orders ON u.id = o.user_id WHERE o.status = 'paid'后，一个用户有 5 笔已付订单，u.name就会返回 5 次 - 若后续要
GROUP BY或统计人数，必须加DISTINCT或COUNT(DISTINCT u.id)，否则数据失真
检查子查询是否为非相关子查询（non-correlated）
相关子查询（即子查询里引用了外层表字段，如 WHERE o.user_id = u.id）本身无法直接转为简单 JOIN；但若子查询不依赖外层（如 SELECT id FROM shops WHERE owner_id = ?），就具备改写基础：
- MySQL 5.6–8.0 中，这类 IN 常被优化器识别为
DEPENDENT SUBQUERY，导致外层每行都重跑子查询 - EXPLAIN 看到
type是ALL或index且Extra含Using where; Using join buffer，说明已退化 - 此时改写为
INNER JOIN shops s ON u.shop_id = s.id AND s.owner_id = ?才可能触发索引下推
验证关联字段是否有有效索引
没索引的 JOIN 和没索引的 IN 一样慢，甚至更糟——因为 JOIN 还要构建连接缓冲区：
- 对子查询中的表（如
orders），至少要有(user_id)单列索引；若带过滤条件（如status = 'paid'），优先建联合索引(user_id, status) - 用
SHOW INDEX FROM orders查看key_name是否存在，别只信命名习惯 - JOIN 后再跑
EXPLAIN，确认key列非空、rows显著下降、Extra不含Using temporary; Using filesort
警惕应用层传入大列表时的误操作
后端拼 IN (1,2,3,...,5000) 看似简单，但实际隐患比子查询还多：
- 超过
max_allowed_packet直接报错，MySQL 默认常为 4MB，5000 个整数约 20KB，看似安全，但加上其他字段和注释就容易超 - SQL 解析开销随值数量线性增长，尤其在高并发下，解析器 CPU 成瓶颈
- 临时表 + JOIN 是更稳的选择：
CREATE TEMPORARY TABLE temp_ids (id BIGINT PRIMARY KEY)，再INSERT批量写入，最后JOIN temp_ids - 别用 CTE（
WITH t AS (...)）替代——MySQL 8.0 默认不物化，大结果集下仍可能反复执行
最常被忽略的一点：改完 JOIN 后，如果原查询本该保留 NULL 匹配（比如用 NOT IN），INNER JOIN 会彻底过滤掉无关联行，语义已变。这种时候，NOT EXISTS 才是安全替代。
