exists是存储过程中判断记录存在的最轻量可靠方式，它通过相关子查询实现短路匹配，找到首行即停，不构造结果集，性能远超count(*)；关键须确保子查询引用外层字段，避免误写为独立查询。
直接用 EXISTS 判断记录是否存在，是存储过程中最轻量、最可靠的方式；它不依赖返回值数量，不构造中间结果集，找到第一条就停，比 COUNT(*) 快得多——尤其在大表或高并发场景下。
EXISTS 在存储过程里怎么写才不白写
很多人把 EXISTS 当成普通函数用，随手写个独立子查询，结果逻辑全错。关键点只有一个：子查询必须“相关”，也就是要引用外层（主查询）的字段，否则数据库只执行一次，所有行都得到同一个布尔结果。
- 错误写法：
IF EXISTS (SELECT 1 FROM users WHERE status = 'active')—— 这查的是“系统里有没有活跃用户”，和当前处理的订单/客户完全无关 - 正确写法：
IF EXISTS (SELECT 1 FROM orders o WHERE o.user_id = @user_id AND o.status = 'pending')—— 每次拿传入的@user_id去查，才是真判断 - 子查询中
SELECT 1、SELECT NULL、SELECT *效果一样，MySQL 和 SQL Server 都只看有没有行，不解析列内容
在 IF EXISTS / WHILE 循环里用 EXISTS 的典型陷阱
SQL Server 存储过程中常用 IF EXISTS 控制流程，但容易忽略作用域和空值问题。
-
@user_id是NULL时，o.user_id = @user_id永远为UNKNOWN，整个EXISTS返回FALSE，哪怕表里真有匹配数据——得加IS NOT NULL显式判断 - 不要在
WHILE循环里反复执行相同EXISTS而不缓存结果，比如先查一次存在性，再进循环体做业务逻辑，否则可能重复扫描 - SQL Server 中
IF EXISTS (SELECT ...)后面不能直接跟变量赋值语句，必须用BEGIN...END包裹多条语句
EXISTS 和 COUNT(*) 在存储过程性能上差多少
差别不是“快一点”，而是“量级不同”。特别是当你要在循环中高频调用、或子查询表有百万级数据时。
-
EXISTS：找到第一条user_id = 123的订单就退出，走索引 B+ 树最多几层 IO -
IF (SELECT COUNT(*) FROM orders WHERE user_id = 123) > 0：必须统计全部匹配行数，即使只有 1 行也要扫完整个索引范围，还额外消耗内存计数 - 实测案例：某订单表 800 万行，
user_id有索引，EXISTS平均耗时 0.8ms，COUNT(*)平均 12ms —— 差 15 倍，且COUNT波动大
为什么有时候 EXISTS 反而变慢了
不是 EXISTS 本身有问题，而是没配好环境。
- 子查询关联字段没索引：比如用
o.created_at > @cutoff但没在created_at上建索引，EXISTS就退化成全表扫描 - 写了
SELECT *在子查询里又加了ORDER BY或LIMIT 1：多余，EXISTS自带短路，加这些反而干扰优化器 - 跨库或视图嵌套太深：某些版本 MySQL 对多层派生表的
EXISTS推导能力弱，可能放弃使用索引，这时得拆成临时表或改用JOIN
真正难的不是写对语法，而是让每一条 EXISTS 都落在索引可覆盖的路径上——查执行计划比背语法重要十倍。
