子查询在WHERE中用于动态行级过滤，本质是返回允许访问的主键值；必须显式传入用户标识、类型兼容、避免隐式转换，并配合应用层参数化与索引优化。
子查询用在 WHERE 里过滤行，不是用来“控制权限”的抽象概念
SQL 没有内置的“权限访问控制”语法，所谓行级权限，本质就是对 SELECT 结果做动态过滤。子查询在这里只干一件事：在 WHERE 中返回一组允许访问的主键或标识值，让外层查询只捞出这些行。
常见错误是把子查询写成独立语句、或放在 FROM 子句里徒增复杂度；也有人误以为加个子查询就自动带权限校验，其实它完全不感知用户身份，必须显式传入当前用户标识（比如 current_user_id）。
- 子查询必须返回单列，且类型要和外层被过滤字段兼容（如
user_id IN (SELECT id FROM allowed_users...)） - 不能依赖数据库会话变量自动识别用户——除非你用的是 PostgreSQL 的
current_setting('app.user_id')这类机制，但那是额外设计，不是 SQL 标准行为 - MySQL 8.0+ 和 PostgreSQL 支持
LATERAL，但多数权限场景不需要，过早引入反而难调试
PostgreSQL 中用 EXISTS 实现高效行级过滤
EXISTS 比 IN 更适合权限判断，因为它可以提前终止、支持关联字段下推，且天然规避 NULL 带来的逻辑陷阱（IN 遇到子查询返回 NULL 时整行被丢弃）。
典型场景：查订单，但只返回当前销售员自己创建的，或所属团队能看的：
SELECT o.* FROM orders o
WHERE EXISTS (
SELECT 1 FROM sales_teams st
JOIN team_members tm ON st.id = tm.team_id
WHERE st.id = o.team_id
AND tm.user_id = 123 -- 当前用户 ID，应由应用层注入
);- 别在子查询里写
SELECT *，只用SELECT 1即可，语义清晰且数据库优化器更易处理 - 确保
sales_teams.id、team_members.team_id、team_members.user_id有索引，否则嵌套扫描极慢 - 如果权限规则涉及多层继承（如部门→子部门→岗位），子查询里用递归 CTE 更稳，但别直接塞进
EXISTS，先物化到临时表或用WITH
MySQL 5.7 下 IN 子查询的隐式类型转换坑
MySQL 对 IN 右侧子查询的字段类型敏感，若外层是 BIGINT（比如用户 ID 是雪花 ID），而子查询返回 VARCHAR，就会触发全表隐式转换，索引失效，查询变慢十倍以上。
错误示例：WHERE user_id IN (SELECT user_code FROM permissions WHERE role = 'editor')，其中 user_code 是字符串型 ID。
- 检查执行计划：
EXPLAIN看type是否为ALL或index，而不是ref/eq_ref - 强制类型一致：
WHERE user_id IN (SELECT CAST(user_code AS SIGNED) FROM permissions...)，但不如源头统一字段类型 - 避免用字符串存数字 ID；如果必须，子查询里用
CONVERT(user_code, UNSIGNED)，注意溢出风险
子查询权限模型绕不开的应用层配合点
SQL 子查询本身不认人，所有用户上下文（如当前登录者 ID、角色列表、租户 ID）都得由应用层拼进来。漏传、错传、硬编码测试值，是线上权限绕过的最常见原因。
例如，本该是 AND tm.user_id = ?，却写成 AND tm.user_id = 1；或忘记对多租户场景加 tenant_id = ? 条件，导致跨租户数据泄露。
- 永远用参数化查询，禁止字符串拼接用户输入，尤其别把
user_id直接插进 SQL 字符串 - 在 DAO 层封装权限子查询逻辑，不要每个业务 SQL 都重写一遍，否则改规则时漏改一处就出问题
- 测试时务必覆盖“无权限”路径：子查询返回空结果集时，外层是否真的一行都不返回？别只测“有数据”的 happy path
真正麻烦的从来不是怎么写那个子查询，而是怎么确保每次执行它的时候，传进去的用户上下文既准确又完整——这事儿数据库管不了，得靠代码里的约束和测试卡住。
