EXISTS比COUNT()>0更合适，因其找到首行即返回TRUE，不扫描全表；而COUNT()需遍历全部结果集，性能差且在标量上下文中可能报错。
IF EXISTS 为什么比 SELECT COUNT(*) > 0 更合适
因为 EXISTS 在找到第一行匹配就立即返回 TRUE，不扫描全表；而 COUNT(*) 必须遍历整个子查询结果集，即使只关心“有没有”。尤其在大表或带复杂 JOIN 的子查询中，性能差距明显。
常见错误是写成 IF (SELECT COUNT(*) FROM ...) > 0 —— 这不仅多算，还可能因子查询返回多行报错（如在标量上下文中）。
-
EXISTS只关心逻辑存在性，不返回数据，天然适配IF判断 - 子查询里用
SELECT 1或SELECT *都可以，优化器会忽略字段列表 - 注意：子查询不能有聚合（如
GROUP BY）或ORDER BY（除非配合LIMIT，但通常没必要）
SQL Server 中 IF EXISTS 的标准写法
SQL Server 支持直接在批处理中用 IF EXISTS 控制流程，但必须确保子查询语法正确、作用域清晰。
典型结构：
IF EXISTS (SELECT 1 FROM users WHERE status = 'pending')
BEGIN
PRINT '有未处理用户';
-- 执行更新/插入等操作
END
ELSE
BEGIN
PRINT '无待处理记录';
END
- 子查询括号不能省略，否则语法错误
-
BEGIN...END在单条语句时可省，但建议始终保留，避免嵌套逻辑出错 - 若子查询引用外部表（相关子查询），需确认别名和作用域，例如
WHERE u.id = t.user_id中u必须已在外层定义
MySQL 不支持 IF EXISTS 直接写法？用 CASE 或存储过程替代
MySQL 的普通 SQL 语句中不能直接写 IF EXISTS(...) 控制流 —— 这是常见困惑点。它只允许在存储过程、函数或触发器内使用 IF 语句。
如果只是想在查询中返回“是否存在”的标记，用 CASE WHEN EXISTS：
SELECT
id,
name,
CASE WHEN EXISTS (SELECT 1 FROM orders WHERE user_id = u.id)
THEN 1 ELSE 0 END AS has_order
FROM users u;
- 不能在普通客户端执行
IF EXISTS ... BEGIN ... END，会报语法错误ERROR 1064 - 想实现类似 SQL Server 的逻辑控制，必须封装进存储过程，且调用时用
CALL proc_name() - 注意 MySQL 8.0+ 支持 CTE，但
EXISTS子查询本身兼容所有版本
PostgreSQL 怎么安全地用 EXISTS 做条件判断
PostgreSQL 允许在 WHERE、HAVING、CTE 和 WITH 中自由使用 EXISTS，但要注意相关子查询的 NULL 处理和性能提示。
比如删除前校验依赖：
DELETE FROM products WHERE id = 123 AND NOT EXISTS (SELECT 1 FROM order_items WHERE product_id = products.id);
-
NOT EXISTS对空集返回TRUE，对非空集返回FALSE，行为确定 - 若子查询中列可能为
NULL（如WHERE col = NULL），应改用IS NULL，否则条件恒假 - 在大表上使用时，确保子查询关联字段有索引，否则
EXISTS可能退化为嵌套循环扫描
实际写的时候最容易忽略的是子查询的关联字段是否可为空，以及数据库方言对控制语句的支持边界——不是所有地方都能把 EXISTS 当开关用，得先看引擎认不认这个语法。
