EXISTS性能取决于子查询能否快速退出，核心是确保索引命中：需为关联及过滤字段建索引，避免对索引字段使用函数。
用 EXISTS 做存在性判断，关键不是“有没有数据”，而是“能不能快速确认有”。优化核心是让子查询尽早退出，避免全表扫描。
确保子查询能走索引
EXISTS 的性能几乎完全取决于子查询的执行效率。如果子查询没有命中索引，即使外层只查 1 行，也可能触发内层全表扫描。
- 检查子查询 WHERE 条件中的字段是否建了合适的索引（尤其是关联字段和过滤字段）
- 避免在子查询中对索引字段做函数操作，比如 WHERE DATE(create_time) = '2024-01-01' 会失效索引，应改写为 create_time >= '2024-01-01' AND create_time
- 复合索引要注意最左前缀原则，例如子查询条件是 WHERE user_id = ? AND status = 1，索引应建为 (user_id, status) 而非反过来
优先用 EXISTS 而非 IN 或 JOIN
当只需判断存在性、不需取值时，EXISTS 天然适合短路逻辑：找到第一行就返回 true，无需继续遍历。
- IN 在子查询结果为空或含 NULL 时行为复杂，且 MySQL 可能将 IN 改写为 JOIN，导致全量匹配
- LEFT JOIN + IS NOT NULL 判断存在性，会生成临时结果集，比 EXISTS 多出连接和字段填充开销
- 典型推荐写法：SELECT 1 FROM t1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.t1_id = t1.id AND t2.status = 1)
精简子查询内容，只保留必要条件
EXISTS 子查询中 SELECT 后面的内容无关紧要（MySQL 会忽略），但写法会影响可读性和优化器判断。
- 固定写 SELECT 1 或 SELECT NULL，不要写 SELECT * 或具体字段
- 去掉子查询中无意义的 ORDER BY、LIMIT、GROUP BY —— 它们不仅无效，还可能干扰优化器选择执行计划
- 如果子查询本身带复杂逻辑（如多表 JOIN），先确认是否真有必要；有时把条件前置到外层或拆成独立判断更高效
注意相关子查询与非相关子查询的区别
相关子查询（含对外层表的引用）会为外层每一行执行一次，此时索引和过滤效率尤为关键；非相关子查询只执行一次，但 MySQL 8.0+ 才常做物化优化。
- 若外层数据量大，而子查询又无法高效过滤，考虑是否可改用临时表预存中间结果
- 用 EXPLAIN 观察 type 字段：出现 DEPENDENT SUBQUERY 表示相关子查询，rows 值应尽量小；若显示 SUBQUERY 或 MATERIALIZED，说明是非相关或已优化
- 必要时加 STRAIGHT_JOIN 或 USE INDEX 提示，但应以执行计划为准，而非盲目加 Hint
