group by 仅执行分组聚合，不处理权限；多级权限汇总必须前置过滤（where/rls）再分组，执行顺序为 where→group by→having→order by，权限字段不可混入group by以免分组爆炸。
直接说结论：GROUP BY 本身不处理权限逻辑，它只做分组聚合；多级权限下的数据汇总显示，必须靠前置的数据过滤（如 WHERE 或行级安全策略） + 后置的分组逻辑组合实现，不能指望 GROUP BY 自动识别“谁能看到哪一层”。
权限过滤必须在 GROUP BY 之前完成
很多人误以为加个 GROUP BY region, city, shop 就能自动按用户权限“切片汇总”，其实不然。数据库执行顺序是 WHERE → GROUP BY → HAVING → ORDER BY。如果用户只能看“华东区”，就必须先用 WHERE region = 'East' 或通过视图/RLS（行级安全）把非授权数据剔除干净，再分组——否则 GROUP BY 会照常聚合全量数据，结果完全失真。
- 常见错误：在应用层查出全部数据后，再用代码按权限“筛完再 group”，这既浪费带宽又容易漏逻辑
- 正确做法：把权限条件写进 SQL 的
WHERE子句，或使用数据库原生 RLS（如 PostgreSQL 的CREATE POLICY、MySQL 8.0+ 的行级权限插件） - 若用视图封装，注意视图定义里必须包含权限字段（如
user_id、org_level），且查询时仍需传入当前用户上下文（如WHERE org_id IN (SELECT org_id FROM user_orgs WHERE user_id = @current_user)）
GROUP BY WITH ROLLUP 生成的 NULL 行不是“权限层级”，而是物理汇总标记
比如管理员看全国数据，销售主管只看本省，GROUP BY region, city WITH ROLLUP 产生的 (‘Jiangsu’, NULL) 是江苏省小计，但这个小计对所有人可见——它不随用户身份动态变化。它只是语法层面的聚合占位符，和权限无关。
-
NULL行代表“该位置上卷”，不是“当前用户无权查看”，别把它当权限开关 - 想让不同角色看到不同层级的汇总（比如主管只看到
city级，总监看到region级），得用不同 SQL：一个查GROUP BY city，另一个查GROUP BY region，而不是依赖同一个ROLLUP结果去“解释” - 若硬要用同一语句适配多角色，可加
CASE WHEN GROUPING(city) = 1 AND GROUPING(region) = 0 THEN 'Province Total' ELSE city END做标签美化，但底层数据仍是全量聚合后的结果
避免在 GROUP BY 中混用权限字段导致分组爆炸
比如表里有 user_role 字段，有人写 GROUP BY region, city, user_role 想“按角色区分汇总”，结果发现每个城市都拆成 admin/sales/manager 多行——这不是权限控制，是把权限字段当普通维度参与了分组，反而掩盖了真实业务粒度。
- 权限字段（如
role、dept_id）通常不应出现在GROUP BY列表里，除非你明确要统计“各角色在某城市的订单数”这类交叉指标 - 真正控制可见性的字段（如
visible_to_dept）应只用于WHERE过滤，而非分组依据 - 若需“按部门汇总并限制仅本部门可见”，正确结构是：
WHERE dept_id = @current_dept GROUP BY region, city，而不是GROUP BY dept_id, region, city
最易被忽略的一点：权限逻辑和分组逻辑必须解耦。用 GROUP BY 做汇总，用 WHERE 或数据库安全机制做过滤，两者职责清晰才不会在复杂场景下互相污染。一旦开始用 IF(GROUPING() = 1, ...) 去模拟权限判断，说明架构已经偏离正轨了。
