EXISTS更适合高并发鉴权，因其执行短路机制——找到一条匹配即返回TRUE，配合user_role(user_id,role_id)和role_permission(role_id,permission_code)联合索引可避免全表扫描与临时表，而IN需物化全部结果集，易引发性能抖动。
EXISTS 比 IN 更适合高并发鉴权的底层原因
在用户请求到达网关或业务层做权限校验时，频繁查 user_role、role_permission 这类关联表，用 IN 容易触发全表扫描或临时表，而 EXISTS 能利用索引快速短路——只要找到一条匹配就返回 TRUE，不继续查。尤其当权限数据量大、但多数用户权限有限时，EXISTS 的平均响应时间更稳定。
关键点在于：数据库优化器对 EXISTS 通常生成 SEMI JOIN 执行计划，配合 role_id 或 permission_code 上的联合索引，能跳过大量无关行。
鉴权 SQL 中 EXISTS 的标准写法与索引要求
假设校验用户 user_id = 123 是否拥有 'api:order:delete' 权限，典型结构如下：
SELECT 1 FROM dual WHERE EXISTS ( SELECT 1 FROM user_role ur INNER JOIN role_permission rp ON ur.role_id = rp.role_id WHERE ur.user_id = 123 AND rp.permission_code = 'api:order:delete' );
必须确保以下索引存在，否则 EXISTS 优势归零：
-
user_role(user_id, role_id)—— 覆盖查询条件 + 关联字段 -
role_permission(role_id, permission_code)—— 同样需覆盖关联和过滤
避免只建单列索引，例如 user_role(user_id) 单独存在，role_id 仍要回表，高并发下 I/O 压力明显上升。
嵌套 EXISTS 易踩的性能坑
有些同学会把多级权限（如租户 → 角色 → 权限）写成三层 EXISTS 嵌套，例如再加一层 tenant_role 校验。这会导致执行计划退化为多次独立子查询，且难以利用复合索引。
更稳妥的做法是扁平化连接：
SELECT 1 FROM dual WHERE EXISTS (
SELECT 1 FROM user_role ur
INNER JOIN role_permission rp ON ur.role_id = rp.role_id
INNER JOIN tenant_role tr ON ur.role_id = tr.role_id
WHERE ur.user_id = 123
AND rp.permission_code = 'api:order:delete'
AND tr.tenant_id = 456
);
注意：tenant_role 表上必须有 (role_id, tenant_id) 索引，否则 tr.tenant_id = 456 过滤失效。
应用层调用时的缓存与兜底逻辑
即使 SQL 已优化，高并发下仍建议在应用层加两级缓存：
- 本地缓存（如 Caffeine）存
user_id + permission_code → boolean，TTL 控制在 30–60 秒，避免缓存雪崩 - Redis 缓存失败时的兜底结果，键格式为
auth:u123:p_api:order:delete，设 5 分钟过期
特别注意：权限变更后要主动清理对应缓存，不能只依赖过期；否则会出现“刚授予权限却鉴权失败”的现象。清理动作建议走异步消息，避免阻塞主流程。
最常被忽略的是 EXISTS 子查询里漏写 WHERE 关联条件，导致变成笛卡尔积校验——语义错误且性能爆炸，上线前务必用 EXPLAIN 看 rows 和 type 字段。
