WHERE中直接过滤用户ID比JOIN后过滤更安全，因避免优化器提前展开JOIN导致未授权数据暴露；需确保字段有索引，并用SECURITY DEFINER函数封装当前用户标识。
WHERE条件里写用户ID过滤比JOIN后过滤更安全
直接在WHERE子句中加入当前用户标识（如user_id = current_user_id()），比先JOIN再用WHERE筛更可靠。因为数据库优化器可能把JOIN提前展开，导致中间结果暴露未授权数据。
常见错误现象：视图定义里用JOIN users u ON u.id = orders.user_id，然后在应用层加WHERE u.id = ?——这等于把全量订单和用户表先连上，再砍掉部分行，执行计划里很可能扫描了不该看的订单。
- 正确做法是把权限判断下沉到最外层
WHERE，且确保该字段有索引（比如orders.user_id） - 如果用PostgreSQL，可配合
SECURITY DEFINER函数封装current_user_id()，避免应用传入伪造ID - MySQL 8.0+ 可用
USER()或自定义会话变量，但要注意SQL SECURITY DEFINER对变量不可见，得改用函数封装
用WITH RECURSIVE实现角色继承时别漏掉循环检测
当权限模型支持“角色A属于角色B，B又属于C，C反过来属于A”这种环状继承时，WITH RECURSIVE默认不会报错，而是无限递归直到超时或栈溢出。
使用场景：企业级系统里RBAC常带多级角色嵌套，管理员可能无意配出循环依赖。
- 必须在
RECURSIVECTE里加路径记录字段（如ARRAY[role_id]），并在WHERE中检查role_id = ANY(path) - PostgreSQL示例：
SELECT ... FROM roles r JOIN role_inherit ri ON r.id = ri.parent_id WHERE NOT r.id = ANY(path) - SQL Server用
MAXRECURSION 100只能防崩，不能防逻辑错；真正要的是路径去重逻辑
VIEW定义里不能用参数化输入，得靠函数包装
标准SQL视图不接受参数，所以CREATE VIEW user_orders AS SELECT * FROM orders WHERE user_id = ?会直接报错：ERROR: syntax error at or near "?"。
性能影响：有人用EXECUTE format('SELECT * FROM orders WHERE user_id = %L', uid)拼字符串，看似灵活，实则无法走索引、易被注入、计划缓存失效。
- PostgreSQL推荐用
SECURITY DEFINER函数返回SETOF orders，内部查current_setting('app.user_id') - MySQL可用存储函数，但注意
SQL SECURITY DEFINER下无法读会话变量，得用CONNECTION_ID()查连接级临时表 - 别在视图里调用
NOW()或RANDOM()这类不稳定函数，会导致物化视图刷新异常或查询结果不一致
LEFT JOIN + 权限字段NULL判断容易绕过权限控制
写LEFT JOIN permissions p ON p.resource_id = orders.id AND p.user_id = current_user_id()，再WHERE p.user_id IS NOT NULL，看起来能过滤，但只要permissions表缺失某条记录，整行就消失——这本身没问题；问题在于，如果业务逻辑依赖orders主表存在性（比如统计总数），这个JOIN会让没权限的用户看到“空结果”，而他们本该看到“403”而不是“0条”。
- 更稳妥的方式是用
EXISTS子查询：WHERE EXISTS (SELECT 1 FROM permissions p WHERE p.resource_id = orders.id AND p.user_id = current_user_id()) -
EXISTS语义清晰：只关心“能不能看”，不改变主表行数，也更容易命中索引（尤其(resource_id, user_id)联合索引） - 如果真要用
LEFT JOIN，务必确认下游代码是否把“无匹配行”当成“无数据”而非“无权限”——这是最容易被忽略的语义断层
权限过滤的位置、方式、边界条件，三者稍有偏差就会让安全策略形同虚设。特别是当多个JOIN和子查询混在一起时，数据库优化器可能重排执行顺序，把本该前置的过滤推后。上线前得用EXPLAIN ANALYZE盯住实际执行路径，不能只信SQL字面意思。
