EXISTS 并非万能加速器，仅在关联字段有索引且子查询可短路时才高效；漏写外层关联会导致逻辑错误，应使用 SELECT 1 并确保索引覆盖关联字段前缀。
EXISTS 不是万能加速器，它只在关联条件有索引、子查询能短路时才真正快；没索引或写错关联，比 IN 还慢。
EXISTS 必须关联外层表，否则逻辑全错
常见错误是漏写子查询里的关联条件，导致子查询脱离上下文，变成恒真或恒假判断。比如查“有订单的客户”，写成 WHERE EXISTS (SELECT 1 FROM orders)，结果会返回所有客户——因为子查询不依赖外层 c，永远有数据。
- 正确写法必须显式关联：
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id) - 如果要加额外条件（如“订单状态为 shipped”），必须放在子查询的
WHERE里，且仍保留关联字段 - 别在子查询里用
GROUP BY或聚合函数（如COUNT(*)）而不带HAVING和外层关联，否则会报错或语义错乱
子查询里用 SELECT 1，不是 SELECT * 或 SELECT COUNT(*)
EXISTS 只关心“有没有行”，不关心内容。用 SELECT * 会让数据库多读列、多传输数据；用 SELECT COUNT(*) > 0 更糟——它强制扫描全部匹配行才能返回结果，彻底失去短路能力。
- ✅ 推荐：
SELECT 1（轻量、语义清晰） - ⚠️ 可接受：
SELECT NULL或任意常量，但别用字段名 - ❌ 避免：
SELECT *、SELECT customer_id、SELECT COUNT(*)
索引必须建在子查询的关联字段上，且是前缀匹配
执行计划里看到 type: index_subquery 或 Extra: Select tables optimized away 是好信号；如果显示 type: ALL 或 rows 值巨大，基本就是没走索引。
- 检查索引是否存在：
SHOW INDEX FROM orders（MySQL）或\d orders（PostgreSQL） - 关键字段（如
orders.customer_id）必须有单列索引，或至少是复合索引的最左前缀（(customer_id, status)可用，(status, customer_id)不可用） - 字段允许
NULL会影响优化器对半连接的识别，业务允许时建议加NOT NULL约束 - 避免在关联字段上套函数，比如
WHERE DATE(created_at) = '2026-08-12'会让created_at索引失效
别硬套 EXISTS，JOIN 或 IN 有时更合适
EXISTS 的优势只在“纯存在性判断”场景成立。一旦你需要取子表字段、去重、或做聚合，它就不再是最佳选择。
- 要取订单金额、时间等字段？直接
JOIN，别绕EXISTS+ 再查一遍 - 子查询结果很小（IN 可能更快，尤其 MySQL 8.0+ 对
IN (SELECT ...)有物化优化 - 查“没有订单的客户”？
NOT EXISTS比LEFT JOIN ... IS NULL更直观，但要注意NULL字段是否参与关联条件
真正卡住性能的，往往不是语法选错，而是索引缺失或关联条件写飘了。跑一次 EXPLAIN，盯住子查询那行的 type 和 rows，比背十遍规则都管用。
