不能在分组查询中用WHERE或HAVING实现行级权限过滤，因其无法获取用户上下文；正确做法是先通过视图结合会话变量（如current_setting、SESSION_CONTEXT）完成行级过滤，再对过滤结果分组。
不能在分组查询里靠 WHERE 或 HAVING 实现真正的行级权限过滤 —— 它们不认用户上下文，只认数据本身。
为什么 WHERE 和 HAVING 都没法做权限过滤
WHERE 在分组前执行，HAVING 在分组后执行，但两者都只对当前查询可见的数据起作用。它们无法动态获取“谁在查”这个信息：没有数据库会话变量、不调用 current_setting()、SESSION_CONTEXT() 或 ORIGINAL_LOGIN()，就只是静态条件。比如写 WHERE dept_id = 101，所有用户看到的都是 dept_id=101 的数据，根本不是“各自能看的部门”。
- 硬编码值（如
WHERE user_id = 123）等于没做权限控制 - 用
USER()或CURRENT_USER得到的是连接池账号（如app_user@localhost），不是真实业务用户 -
HAVING只能筛组，不能筛行；哪怕你HAVING COUNT(*) > 0，它也不会拦住用户查别人的数据
正确做法：先用视图封装权限逻辑，再分组
权限过滤必须在分组之前完成，且依赖数据库运行时能识别当前请求者的机制。典型路径是：视图定义里嵌入用户上下文 → 视图输出已过滤的行 → 对这个视图再 GROUP BY。
- PostgreSQL：视图中用
WHERE tenant_id = (current_setting('app.tenant_id', true)::int)，应用层提前SET app.tenant_id = '456' - SQL Server：视图中用
WHERE user_id = CAST(SESSION_CONTEXT(N'user_id') AS INT)，应用层先EXEC sp_set_session_context @key=N'user_id', @value=456 - MySQL 8.0.22+：直接启用 RLS（
CREATE POLICY），而不是在视图里硬拼WHERE；旧版本建议改用带参数的存储过程 - 务必收回底层表的
SELECT权限，只授予视图的SELECT权限，否则用户可绕过视图直查原表
分组时容易踩的性能坑
权限过滤后的数据集如果仍很大，GROUP BY 可能变慢，尤其当过滤字段没索引、或用了函数处理时。
- 确保视图底层表的权限字段（如
tenant_id、dept_id）上有索引 - 避免在视图
WHERE条件里对字段做函数转换，比如SUBSTRING(dept_path, 1, 5) = 'D001/'会让索引失效；改用dept_path LIKE 'D001/%' - 层级部门场景下，若递归查询结果超千行，别在视图里实时
WITH RECURSIVE，改用物化中间表或定时刷新 - 不要在视图里
JOIN权限配置表 + 多层EXISTS子查询，执行计划极易退化为嵌套循环
最常被忽略的一点：权限和分组必须分两层实现
很多人试图把权限判断塞进 HAVING，比如 HAVING user_id = CURRENT_USER，这是无效的：HAVING 作用于聚合结果，而 user_id 如果不在 GROUP BY 列里，甚至语法都不通。真正安全的链路永远是：连接建立 → 设置会话变量 → 视图按变量过滤行 → 对过滤后结果分组。漏掉任何一环，权限就形同虚设。
