EXISTS比IN更安全高效，因EXISTS仅判断子查询是否存在行，不取实际数据，规避NULL导致条件判为UNKNOWN的问题；典型写法需显式关联主表字段并用SELECT 1；角色继承场景须用WITH RECURSIVE展开权限链。
WHERE子句里用EXISTS判断用户是否有某角色权限
直接在主查询的WHERE条件中嵌套EXISTS，比IN更安全、更高效，尤其当角色表存在NULL值或需要关联多字段时。EXISTS只关心子查询是否返回至少一行，不实际取数据，避免了IN对空值的意外行为（比如user_id IN (SELECT role_user.user_id FROM ...)遇到NULL会整个条件判为UNKNOWN）。
典型写法：
SELECT * FROM resource r
WHERE EXISTS (
SELECT 1 FROM role_user ru
JOIN role_permission rp ON ru.role_id = rp.role_id
WHERE ru.user_id = ? AND rp.permission_code = 'edit_article'
AND rp.resource_id = r.id
);-
?是传入的用户ID参数，别硬编码 - 子查询里必须把主表字段（如
r.id）显式关联进来，否则变成笛卡尔积或逻辑错误 - 别漏掉
SELECT 1——用SELECT *没意义，还可能触发不必要的列解析
用WITH递归CTE展开角色继承链再过滤
当系统支持“角色继承”（比如管理员角色继承编辑角色权限），单纯JOIN两层不够，得先算出用户最终拥有的所有角色ID集合，再查权限。这时候WITH RECURSIVE不是炫技，是刚需。
假设role_inherit(parent_id, child_id)存继承关系，用户ID为123：
WITH RECURSIVE user_roles AS ( SELECT role_id FROM role_user WHERE user_id = 123 UNION SELECT ri.child_id FROM role_inherit ri INNER JOIN user_roles ur ON ri.parent_id = ur.role_id ) SELECT DISTINCT r.* FROM resource r JOIN role_permission rp ON rp.resource_id = r.id JOIN user_roles ur ON ur.role_id = rp.role_id WHERE rp.permission_code = 'delete_comment';
- 递归CTE必须有非递归部分（第一行
SELECT）和递归部分（UNION之后），缺一不可，否则报错recursive reference must be in UNION - PostgreSQL默认递归深度限制是100，如果继承链特别长，得加
SEARCH DEPTH FIRST BY role_id SET ordercol并配合WHERE ordercol 控制 - 别忘了
DISTINCT——继承可能导致同一资源被多次匹配
LEFT JOIN + IS NULL做“排除型权限校验”
有些场景不是“用户必须有某权限”，而是“用户不能有某禁止权限”，比如审计员可以看所有订单，但不能看VIP客户的退款明细。这时用LEFT JOIN配合IS NULL比NOT EXISTS更直观，也更容易加索引优化。
示例：查所有非VIP退款单
SELECT o.* FROM order o LEFT JOIN vip_refund_block vrb ON vrb.order_id = o.id AND vrb.block_reason = 'audit_restricted' WHERE o.type = 'refund' AND vrb.order_id IS NULL;
-
block_reason条件必须写在ON里，不能放WHERE——否则LEFT JOIN退化成INNER JOIN，结果全错 - 如果
vip_refund_block表很大，给(order_id, block_reason)建联合索引能显著提速 - 注意NULL语义：这里
vrb.order_id IS NULL表示“没找到任何匹配的禁止记录”，不是“该订单没被标记”
子查询结果集过大导致性能崩了怎么办
当角色/权限表数据量上千万，而子查询又没走索引，EXISTS或IN可能拖慢主查询几十倍。这不是语法问题，是执行计划失控。
- 先用
EXPLAIN ANALYZE确认子查询是否走了索引——重点看Index Scan还是Seq Scan - 检查
role_permission表上是否有(role_id, permission_code, resource_id)联合索引；没有就加，顺序不能错 - 避免在子查询里用函数，比如
UPPER(rp.permission_code) = UPPER(?)会让索引失效，改成rp.permission_code = ?并统一小写存储 - 如果用户角色数极少（比如平均IN (123, 456)常量列表反而更快——数据库能更好预估行数
权限过滤最麻烦的从来不是写法，而是把“谁该看到什么”的业务规则，稳稳地映射到索引可加速的查询结构上。一旦发现慢，别急着换ORM写法，先看执行计划里那个红色的Seq Scan在哪。
