IN/EXISTS查询变慢主因是MySQL优化器误选semi-join策略（如DuplicateWeedout而非FirstMatch）且内表无索引，导致全表扫描；需通过EXPLAIN的select_type和Extra确认是否触发semi-join，并优先补全外表关联字段及内表过滤+关联字段的联合索引。
为什么IN/EXISTS查询突然变慢了
不是子查询本身写错了，而是MySQL优化器在满足条件时自动把IN或EXISTS转成了semi-join，但选的策略不合适——比如本该用FirstMatch却走了DuplicateWeedout，还硬扛着没索引的全表扫描。这种“自动优化”反而让查询从毫秒级拖到秒级甚至超时。
检查EXPLAIN是否真走了semi-join
别只看type是不是ALL或index，重点看Extra列和select_type：
-
select_type出现DEPENDENT SUBQUERY或SUBQUERY，说明没触发semi-join（可能因嵌套在OR里、含GROUP BY等） -
Extra里出现Using join buffer (hash join)、Start temporary、End temporary或Using where; Using join buffer，基本确认走了semi-join - 如果
rows列数值巨大，且key为NULL，说明内表（子查询表）没走索引，semi-join再快也白搭
强制禁用semi-join或指定策略
当优化器选错策略又无法靠索引修正时，可临时干预：
- 加
/*+ NO_SEMIJOIN() */提示（MySQL 8.0.12+）直接关闭semi-join：SELECT /*+ NO_SEMIJOIN() */ * FROM t1 WHERE id IN (SELECT id FROM t2 WHERE ...); - 用
/*+ SEMIJOIN(FIRSTMATCH, DUPLICATEWEEDOUT) */显式指定策略顺序（注意：仅当优化器支持且版本≥8.0.16） - 对老版本（如5.7），改写成
EXISTS有时比IN更稳——但前提是子查询里WHERE条件能命中索引；反之，若子查询结果集极小，IN转成物化临时表反而更快
索引不匹配是半连接性能崩盘的主因
semi-join再聪明，也救不了缺失关键索引的表。重点检查两点：
- 外表（主查询表）的关联字段是否有索引？例如
SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers)，orders.customer_id必须有索引 - 内表（子查询表）的过滤字段+关联字段是否构成联合索引？比如
SELECT * FROM class WHERE class_num IN (SELECT class_num FROM roster WHERE status = 'active')，roster(status, class_num)比单列class_num索引高效得多 - 避免在子查询
WHERE里用函数或表达式，如DATE(created_at) = '2024-01-01'会失效索引，semi-join照样得全扫
真正卡住的往往不是semi-join机制本身，而是它放大了索引缺失的问题——一条没索引的IN子查询原本就慢，semi-join只是让它慢得更“稳定”。
