MySQL存储过程无法直接获取当前用户角色，因CURRENT_USER()和USER()仅返回登录账户而非角色；应通过会话变量（如SET @current_role = 'developer'）或输入参数传入角色标识，并在过程开头校验其存在性。
存储过程里怎么判断当前用户角色？
不能依赖 CURRENT_USER() 或 USER() 直接拿到角色名——它们只返回登录账户（如 'admin@localhost'），不包含角色上下文。必须显式传入或从会话变量/上下文表中获取角色标识。
常见做法是：调用方在执行前设置会话变量，比如 SET @current_role = 'developer';，然后在存储过程中读取 @current_role。或者更稳妥的方式：把角色 ID 作为输入参数传入，避免会话状态污染。
- 若用会话变量，务必在存储过程开头加校验：
IF @current_role IS NULL THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Missing role context'; END IF; - 不建议在存储过程内调用
SELECT ... FROM mysql.role_edges（MySQL 8.0+）反查角色——该表权限受限，且需额外 GRANT，生产环境易出错 - 如果业务已有一套
user_roles表，可用SELECT role_id FROM user_roles WHERE user_id = @current_user_id LIMIT 1查询，但需确保@current_user_id已提前注入
如何根据角色动态限制查询结果范围？
不能靠 WHERE 后硬编码角色条件（如 WHERE role = 'analyst'），而要用角色驱动的数据过滤逻辑。典型场景是“同张表，不同角色看到不同行”。
例如销售表 sales 要实现：管理员看全部，区域经理只看本区域，销售员只看自己的记录。这时应在存储过程中拼接或分支构造 WHERE 条件：
- 用
CASE判断角色后生成过滤子句：AND ( (@current_role = 'admin') OR (@current_role = 'regional_manager' AND region_id = @user_region) OR (@current_role = 'sales_rep' AND creator_id = @current_user_id) ) - 避免用动态 SQL（
CONCAT + PREPARE）拼查询——调试难、SQL 注入风险高、无法利用查询缓存 - 若角色有继承关系（如 manager → team_lead → rep），别在存储过程里递归查
role_hierarchy表；应提前在应用层展开角色集，一次性传入角色数组（如SET @allowed_roles = 'manager,team_lead,rep';），再用FIND_IN_SET匹配
存储过程里执行 INSERT/UPDATE 时怎么校验权限？
权限校验不能只做“能读不能写”的粗粒度控制，要落到字段级和行为级。比如财务角色可改 amount，但不可改 status；审计角色只能 SELECT，不能 UPDATE。
直接在存储过程中用 IF 检查操作类型与角色匹配性：
- 对关键字段变更做显式拦截：
IF @current_role NOT IN ('finance', 'admin') AND NEW.amount != OLD.amount THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Insufficient privilege to modify amount'; END IF; - 不要用
GRANT UPDATE ON sales(amount)这类 MySQL 原生权限替代业务逻辑——它无法表达“仅允许修改自己提交的单据中的 amount”这类复合规则 - 若涉及多表联动更新（如更新订单同时扣减库存），所有相关表的权限检查必须在同一事务内完成，且失败时统一回滚，避免部分写入
为什么存储过程不适合做完整的 RBAC 决策引擎？
因为角色权限规则往往跨多个维度：数据范围（行级）、字段可见性（列级）、操作类型（CRUD）、时间窗口（如“仅工作日 9–18 点可审批”）、甚至外部系统状态（如“需通过风控接口校验才允许放款”）。这些组合爆炸式条件，硬塞进存储过程会导致：
- 每次策略调整都要改存储过程、重新部署、停服验证
- 无法复用已有权限服务（如 OAuth2 scope、Open Policy Agent 策略）
- 测试覆盖难——一个角色 + 一种操作 + 一组数据状态就是一个测试用例，几十个角色就上千条路径
真正可行的做法是：存储过程只做“最小必要校验”，比如确认调用者角色合法、关键字段未越权修改；复杂策略下沉到应用层或独立策略服务，由其返回布尔结果，存储过程只消费这个结果。
