exists本质是存在性断言，只返回true/false；应写select 1而非select *；需确保关联字段有索引（优先联合索引）；复杂逻辑应先生成标签再过滤；注意case分支类型一致及索引覆盖。

WHERE里用EXISTS做布尔判断，本质是“存在性断言”

EXISTS子查询不返回数据，只返回true或false——它不是在“查值”，而是在问“有没有满足条件的记录”。这个特性让它天然适合做分支型布尔判断，比如“是否在黑名单”“是否近7天有退款”，语义比IN或= (SELECT ...)更干净，也更抗NULL干扰。

EXISTS必须写成SELECT 1，别用SELECT *

虽然SELECT *语法合法，但数据库仍要解析所有列定义、可能触发额外I/O甚至内存拷贝。优化器无法跳过字段分析，实际执行开销更大。

• 正确写法：EXISTS (SELECT 1 FROM blacklist b WHERE b.user_id = u.id)
• 错误写法：EXISTS (SELECT * FROM blacklist b WHERE b.user_id = u.id)
• MySQL/PostgreSQL都支持SELECT 1，且明确告诉优化器“只判存在，不取数据”

关联字段没索引，EXISTS会慢到不可接受

EXISTS性能极度依赖内层查询能否快速定位。如果items.order_id没索引，外层每扫一行orders，内层就得全表扫描一次items，复杂度从O(n)变成O(n×m)。

• 必须确保子查询中用于关联外层的字段（如i.order_id）已建索引
• 复合条件优先建联合索引，例如(order_id, qty)比单列order_id更高效
• 用EXPLAIN看执行计划，确认type是ref或range，不是ALL

多层嵌套判断别堆在WHERE里，先算标志再过滤

当逻辑涉及“VIP用户中近7天有退款的标high_risk，否则标high”，直接在WHERE里嵌套两层EXISTS+CASE，可读性差、难调试、执行计划易退化。

• 正确做法：把判断下沉到子查询，生成label字段，外层只做WHERE t.label = 'high_risk'
• 所有CASE分支返回统一类型，例如全用CAST(... AS TEXT)，避免隐式转换影响排序或分组
• label若用于GROUP BY，必须出现在子查询的SELECT列表中，否则报错column must appear in the GROUP BY clause

真正容易被忽略的是类型一致性与索引覆盖——哪怕EXISTS写得再标准，只要关联字段缺索引，或者CASE各分支返回类型不一致，结果就可能错、慢、难维护。