核心是用exists相关子查询逐行校验权限，通过显式关联主表字段（如o.region）实现动态过滤，避免in对null敏感、join导致笛卡尔积等问题，确保每行数据都经布尔判定是否可见。
子查询在 WHERE 中如何关联用户与权限表
行级过滤的核心是：查数据时，每行都得过一遍权限校验。最直接的方式是在主查询的 WHERE 子句里嵌套子查询，判断当前行是否属于当前用户可访问的范围。
假设你有三张表：orders（业务数据）、user_roles（用户-角色关系）、role_permissions（角色-数据范围映射）。比如某角色只能看 region = 'East' 的订单，那子查询就得动态拉出该用户所有角色允许的 region 列表。
- 子查询必须返回单列、多行（用
IN）或标量值（用=/EXISTS），不能返回多列或多行单值 - 避免在子查询中引用主查询未关联的字段——MySQL 会报
Unknown column in field list，PostgreSQL 更严格，可能直接拒绝执行 - 推荐用
EXISTS而非IN：当权限表存在NULL值时，IN (subquery)可能整体返回空结果，而EXISTS不受干扰
示例（安全写法）：
SELECT * FROM orders o
WHERE EXISTS (
SELECT 1 FROM user_roles ur
JOIN role_permissions rp ON ur.role_id = rp.role_id
WHERE ur.user_id = 123
AND rp.resource_type = 'order'
AND rp.filter_key = 'region'
AND rp.filter_value = o.region
);
用相关子查询实现多维度动态过滤（如 region + dept + status）
真实权限常是组合条件，比如“华东区+研发部+状态非已关闭”。这时不能只靠一个 filter_key/filter_value 键值对，得让子查询能一次性验证多个字段是否同时匹配。
关键不是堆条件，而是把权限规则建模成可拼接的逻辑表达式，或拆成多条记录再聚合校验。
- 方案一（推荐）：权限表存为多行，每行一个维度条件，子查询用
COUNT(*) = N确保全部命中。例如用户有 3 条 active 权限规则，则子查询需返回恰好 3 行匹配 - 方案二：用 JSON 字段存规则（如
{"region":"East","dept":"R&D"}），配合数据库 JSON 函数解析比对——但 PostgreSQL 的@>或 MySQL 8.0+ 的JSON_CONTAINS性能较差，且无法走索引 - 严禁在子查询里写
o.region = 'East' AND o.dept = 'R&D'这类硬编码，它会让整个子查询失去动态性，变成静态白名单
组合校验示例（三条件全匹配）：
SELECT * FROM orders o
WHERE 3 = (
SELECT COUNT(*)
FROM user_roles ur
JOIN role_permissions rp ON ur.role_id = rp.role_id
WHERE ur.user_id = 123
AND rp.resource_type = 'order'
AND (
(rp.filter_key = 'region' AND rp.filter_value = o.region) OR
(rp.filter_key = 'dept' AND rp.filter_value = o.dept) OR
(rp.filter_key = 'status' AND rp.filter_value != 'closed')
)
);
性能陷阱：子查询被重复执行导致全表扫描
很多开发者没意识到：在 WHERE 中写的非相关子查询（即不依赖主表字段），某些旧版 MySQL 会为每一行重新执行一次，哪怕结果恒定。这会让本该 O(1) 的权限检查变成 O(n×m)。
- 用
EXPLAIN看执行计划，重点观察子查询是否标记为DEPENDENT SUBQUERY；如果是，说明它被当成了相关子查询，但实际逻辑并不需要依赖——这时要重构，把子查询提前用WITH或临时表固化 - PostgreSQL 对子查询优化更好，但若子查询含
LIMIT或窗口函数，仍可能阻止上层使用索引 - 权限数据变动不频繁，强烈建议加物化视图或缓存中间结果表（如
user_accessible_regions），避免每次请求都 JOIN 三四层
为什么不能只靠 JOIN 实现行级过滤
有人会想：把权限表和主表 JOIN 一下不就完了？但这样会产生笛卡尔积或漏数据——比如用户有 2 个角色，每个角色允许 3 个 region，JOIN 后一条订单可能变成 6 行，去重又可能误杀合法行。
-
JOIN是为了扩展字段，不是为了过滤；行级过滤本质是布尔判定，必须落在WHERE或HAVING里 - 如果硬要用
JOIN，必须配合DISTINCT或GROUP BY，但会丢失原始行结构，且无法处理“任意一个权限满足即可”的逻辑 - 更隐蔽的问题：当用户无任何权限时，
JOIN直接返回空集，而正确行为应是返回主表全量（零权限 = 全部不可见），这只能靠EXISTS或LEFT JOIN ... IS NULL控制
真正干净的行级过滤，子查询不是“可选项”，是语义必需项。它把权限逻辑从数据连接中解耦出来，让每一行的可见性成为独立命题。
