优先用 EXISTS 替代 IN，标量子查询限一层，多层逻辑须拆解，NULL 处理不加过滤即埋雷；IN 遇 NULL 判 UNKNOWN 致静默越权，EXISTS 不受 NULL 影响且更易走索引。
WHERE 子句里嵌套查询不是“能写出来就行”，而是要兼顾正确性、性能和可维护性。直接结论：优先用 EXISTS 替代 IN，标量子查询控制在一层，多层逻辑必须拆解，NULL 处理不加过滤就等于埋雷。
WHERE 中该用 EXISTS 还是 IN？
选错会静默出错，尤其涉及权限、状态校验这类关键逻辑。
-
IN遇到子查询结果含NULL时，整个条件判为UNKNOWN，行被跳过——查不到数据但不报错，典型静默越权 -
EXISTS只关心是否存在匹配行，NULL不影响语义，且数据库优化器更容易走索引 - 必须显式关联外层字段，比如
rp.resource_id = r.id，漏掉就变成非相关子查询，结果全错 - 子查询里写
SELECT 1，别用SELECT *或SELECT 'x'，前者可能触发额外列扫描，后者干扰优化器判断
标量子查询放在 WHERE 里要注意什么？
它只返回一个值，但写错位置或类型不匹配，轻则报错，重则逻辑偏差。
- 只能用于比较运算符右侧：
salary > (SELECT AVG(salary) FROM employees)合法；salary = (SELECT name FROM users WHERE id = 1)报错（类型不匹配） - 子查询必须确定返回单行单列，否则运行时报
Subquery returns more than 1 row - 避免在 WHERE 中嵌套聚合 + 关联字段的“相关子查询”，比如
WHERE salary > (SELECT AVG(salary) FROM employees e2 WHERE e2.dept = e1.dept)—— 每行都执行一次，大数据量下极慢 - 这种场景优先改用窗口函数：
AVG(salary) OVER (PARTITION BY dept)，或先用 CTE 预算好部门均薪再 JOIN
三层及以上嵌套为什么危险？
不是语法不允许，而是执行计划和可读性会快速崩坏。
- 数据库优化器对三层嵌套常放弃索引选择，退化为全表扫描，
EXPLAIN一眼就能看出type: ALL - 像
WHERE x IN (SELECT y FROM t1 WHERE y IN (SELECT z FROM t2 WHERE ...))这种结构，根本没法加有效索引 - 真实业务中，三层逻辑基本都能拆：用 CTE 分步计算中间结果，或用临时表存前两层输出，主查询只扫一次
- 如果真要递归（如角色继承），
WITH RECURSIVE是唯一可靠方式，硬套三层子查询只会漏权限、查不全
最易被忽略的点是：子查询里没索引，比写法错误更致命。哪怕语法完全正确，role_user.user_id 和 role_permission.resource_id 缺索引，EXISTS 查询也会从毫秒变秒级。别只盯着 SQL 写法，先看执行计划里的 key 列有没有命中索引。
