子查询含聚合函数、limit、order by、group by、无索引关联字段、非确定性函数或null未显式过滤时，mysql优化器会禁用半连接改写，退化为逐行执行的dependent subquery。
子查询含聚合或LIMIT时，半连接直接被禁用
优化器看到 COUNT(*)、MAX()、LIMIT 1 或 ORDER BY 就会放弃半连接改写——不是它“不会”，而是语义不允许。半连接只回答“是否存在”，而聚合和排序改变了原始子查询的逻辑含义。
常见错误现象：EXPLAIN FORMAT=TRADITIONAL 中 select_type 显示 DEPENDENT SUBQUERY，且 Extra 列为空或只有 Using where，没有 FirstMatch、LooseScan 等关键词。
- 子查询里写了
SELECT COUNT(*) FROM logs WHERE user_id = u.id→ 必然不走半连接，哪怕只用来判断非零 - 用了
SELECT id FROM orders ORDER BY created_at DESC LIMIT 1→ 即使你只想取“最新一条是否存在”，优化器也无法短路，因为排序+截断不可下推 -
GROUP BY出现在子查询中，哪怕没聚合函数，也会阻断上拉（pull-up）和半连接识别
关联字段缺失索引，优化器不敢生成JOIN执行路径
半连接不是“语法替换”，而是物理执行计划重排；没有索引，优化器无法保证 FirstMatch 或 LooseScan 能真正短路，只能退回到嵌套循环扫描。
使用场景：主表 users 关联子查询中的 orders.user_id，但 orders.user_id 没有索引 → 每次匹配都要全表扫 orders，成本远高于物化临时表。
- 检查方式：
SHOW INDEX FROM orders确认user_id是否在索引列中（单独索引 or 联合索引最左前缀） - 即使
users.id有主键，若orders.user_id没索引，IN (SELECT user_id FROM orders)仍大概率退化为DEPENDENT SUBQUERY - 联合索引如
(status, user_id)对WHERE user_id = ?无效，必须是(user_id, ...)开头
子查询引用了多层外层别名或存在副作用
优化器对相关性判断非常保守。一旦子查询里出现类似 t2.x = t1.y AND t3.z = t2.w 这种跨两层的关联，或者调用了 NEXTVAL、RAND()、用户变量 @var，就会彻底关闭半连接开关。
为什么这样做？因为这类表达式无法静态推导出等价 JOIN 条件，强行改写可能改变执行顺序、触发次数或结果一致性。
-
SELECT * FROM a WHERE id IN (SELECT b.id FROM b WHERE b.ref = a.parent_id AND b.status = (SELECT c.code FROM c WHERE c.id = b.c_id))→ 第二层子查询引入间接依赖，半连接失效 -
SELECT * FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.x = t1.y AND t2.val > RAND())→RAND()是非确定性函数，禁止改写 - 使用
@counter := @counter + 1类变量，哪怕只是调试用途，也会让优化器拒绝所有上拉行为
NULL值处理与语义冲突导致优化器主动回避
IN 和 EXISTS 对 NULL 的敏感性不同，而半连接策略（如 DuplicateWeedout）默认按非 NULL 安全逻辑设计。一旦优化器发现子查询列允许 NULL 且未显式排除，它宁可慢，也不冒险。
容易踩的坑：你以为加了 WHERE col IS NOT NULL 就够了，但若这个条件写在子查询的 ON 子句里（比如手写 JOIN 时），优化器可能无法将其下推到半连接物化阶段。
- 子查询字段定义为
INT NULL，且未在 WHERE 中过滤IS NOT NULL→ 半连接可能被跳过，尤其在NOT IN场景下更危险 -
EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.ref)中，若t2.id允许 NULL，某些 MySQL 版本（如 5.7.30 之前）会拒绝LooseScan策略 -
optimizer_switch='semijoin=off'被意外关闭（例如通过配置文件或会话 SET），会导致所有符合条件的子查询都退化
真正卡住半连接生效的，往往不是“有没有写对语法”，而是索引是否覆盖关联路径、NULL 是否被显式约束、以及子查询里有没有藏着一个看似无害却让优化器瞬间警觉的非确定性表达式。
