EXISTS 比 IN 更适合权限树鉴权，因其找到首条匹配即返回，避免全量扫描子查询结果集；而权限树深、分支多，用户通常仅命中某层节点，EXISTS 显著减少扫描行数。
EXISTS 嵌套子查询为什么比 IN 更适合权限树鉴权
因为 EXISTS 在找到第一条匹配记录后就立即返回 TRUE，不继续扫描；而 IN 需要先执行完整子查询、生成结果集，再做哈希或遍历匹配。权限树往往深且分支多，用户通常只命中某一层节点，EXISTS 能显著减少实际扫描行数。
典型场景：判断用户是否拥有某资源（如 /api/order/export）的访问权限，而权限数据以父子关系存于 permission 表中，含 id、code、parent_id 字段。
-
EXISTS可配合递归 CTE 或自连接向上追溯，但更常见的是用“从目标资源反向查祖先路径是否被授权” - 若用
IN写成WHERE code IN (SELECT code FROM ...)，子查询会把整棵树拉出来，即使用户只缺最顶层权限也会全扫 - MySQL 5.7+、PostgreSQL、SQL Server 均对
EXISTS+ 相关子查询有较好优化，尤其当parent_id和user_id有联合索引时
用 EXISTS 向上遍历权限树的写法（无递归）
假设权限分配表为 user_permission（字段：user_id, perm_id），权限定义表为 permission（字段：id, code, parent_id）。要判断用户 123 是否能访问 '/api/order/export'，需检查该 code 对应节点，或其任意祖先节点，是否在 user_permission 中存在记录。
关键思路：把“查找所有祖先”逻辑压进 EXISTS 子查询，利用自连接模拟向上跳转，限制层级避免无限循环（一般权限树不超过 5 层）：
SELECT EXISTS (
SELECT 1
FROM permission p0
WHERE p0.code = '/api/order/export'
AND (
-- 自身被授权
EXISTS (SELECT 1 FROM user_permission up WHERE up.user_id = 123 AND up.perm_id = p0.id)
-- 或父级被授权（最多向上查 3 层）
OR EXISTS (
SELECT 1 FROM permission p1
WHERE p1.id = p0.parent_id
AND EXISTS (SELECT 1 FROM user_permission up WHERE up.user_id = 123 AND up.perm_id = p1.id)
)
OR EXISTS (
SELECT 1 FROM permission p2
JOIN permission p1 ON p1.id = p2.parent_id
WHERE p2.id = p0.parent_id
AND EXISTS (SELECT 1 FROM user_permission up WHERE up.user_id = 123 AND up.perm_id = p1.id)
)
)
)这种写法直观、兼容性好（无需 CTE），但层级硬编码易出错。更稳的方式是用单层自连接 + OR 链，而非嵌套 EXISTS：
SELECT EXISTS (
SELECT 1
FROM permission p
JOIN user_permission up ON up.perm_id = p.id
WHERE up.user_id = 123
AND (
p.code = '/api/order/export'
OR p.code = (SELECT code FROM permission WHERE id = (
SELECT parent_id FROM permission WHERE code = '/api/order/export'
))
OR p.code = (SELECT code FROM permission WHERE id = (
SELECT parent_id FROM permission WHERE id = (
SELECT parent_id FROM permission WHERE code = '/api/order/export'
)
))
)
)用 WITH RECURSIVE + EXISTS 实现真正动态树遍历
PostgreSQL 和 MySQL 8.0+ 支持递归 CTE，这是处理任意深度权限树的干净方案。核心是先用 WITH RECURSIVE 拿到目标资源的所有祖先 id，再用 EXISTS 判断其中任一是否被用户授权。
注意：递归结果必须包含 id（用于关联 user_permission），不能只查 code，否则无法走索引：
WITH RECURSIVE perm_ancestors AS ( SELECT id, parent_id FROM permission WHERE code = '/api/order/export' UNION ALL SELECT p.id, p.parent_id FROM permission p INNER JOIN perm_ancestors pa ON p.id = pa.parent_id ) SELECT EXISTS ( SELECT 1 FROM perm_ancestors pa INNER JOIN user_permission up ON up.perm_id = pa.id WHERE up.user_id = 123 )
- 递归锚点必须精准命中单条记录（
code应唯一，否则UNION ALL可能爆炸） -
perm_ancestors的id字段务必建索引，否则JOIN user_permission会变全表扫描 - MySQL 8.0 默认递归深度限制为 1000，可通过
SET cte_max_recursion_depth = 100调低防误操作
容易忽略的性能陷阱和修复方式
很多人写了 EXISTS 还是慢，问题往往不在语法，而在数据模型和索引缺失。
- 没给
permission(parent_id)加索引 → 向上遍历时每次JOIN都变全表扫描 -
user_permission(perm_id)有索引，但没加user_id→WHERE user_id = ? AND perm_id = ?无法高效定位 - 权限码（
code）字段没建唯一索引 → 锚点查询可能返回多行，递归 CTE 数据量翻倍 - 在应用层拼接 SQL 时，把用户 ID 写成字符串（如
'123'）导致隐式类型转换，使user_id索引失效
最简验证方式：对最终 EXISTS 子查询单独加 EXPLAIN，确认 type 是 eq_ref 或 ref，且 rows 数量级合理（个位数到百位）。超过千行基本说明某处索引没生效。
权限树的“快”，不来自某一条 SQL 多精巧，而来自每层跳转都有索引兜底，以及递归深度可控——这两点漏掉任何一个，EXISTS 也救不回来。
